Merge https://github.com/stellar/stellar-docs into old-meetings

#2227 duplicates d577b7c which is why I was trying to get this merged in earlier after the January uploads. I tried reaching out to Carsten on Discord but never heard anything back, since I suspected they may duplciate the work. The primatives here change the file route so it's necessary to merge in

Author: JFWooten4

config/theme/navbar.ts

@@ -79,6 +79,11 @@ const build: NavbarItem = {
       label: 'Tutorial: Dapp Frontend',
       activeBasePath: 'docs/build/apps/dapp-frontend',
     },
+    {
+      to: '/docs/build/apps/zk',
+      label: 'ZK Proofs on Stellar',
+      activeBasePath: 'docs/build/apps/zk',
+    },
     {
       type: 'html',
       value: '<hr><a href="/docs/build/guides" class="subtitle"><small>How-To Guides</small>',

docs/build/apps/zk.mdx

@@ -0,0 +1,52 @@
+---
+title: ZK Proofs on Stellar
+sidebar_position: 75
+---
+
+X-Ray (Protocol 25) introduced native host functions for zero-knowledge-friendly primitives (BN254 and Poseidon/Poseidon2), marking an important milestone in a long-term strategy to equip developers with the execution-environment infrastructure needed to build compliance-forward, privacy-preserving applications using zero-knowledge cryptography. These primitives are foundational building blocks and do not, on their own, provide end-to-end private payments without additional higher-level protocol or application logic.
+
+For more details on X-Ray, see this [blog post](https://stellar.org/blog/developers/announcing-stellar-x-ray-protocol-25).
+
+## BN254
+
+BN254 is a pairing-friendly elliptic curve defined over a 254-bit prime field, commonly used in zero-knowledge proof systems because it supports efficient bilinear pairings. These pairings enable succinct proof constructions where complex statements can be verified quickly on-chain or in constrained environments. BN254 is especially popular in blockchain ecosystems because its arithmetic and pairing operations are relatively efficient to implement and well supported by existing libraries and tooling.
+
+While BN254 host functions provide the cryptographic operations needed for proof verification, developers must still generate proofs using higher-level systems (such as circuits written in Noir or Risc0 methods) and deploy verifier smart contracts on Stellar to implement complete zero-knowledge workflows.
+
+### BN254 host functions
+
+- `g1_add` — adds two elliptic-curve points in the G1 group, producing a new point. This is commonly used to combine proof or verification values.
+- `g1_mul` — multiplies a G1 elliptic-curve point by an integer, returning a new point. This operation is a core building block in many proof verification calculations.
+- `pairing_check` — verifies a pairing equation over lists of G1 and G2 points. This is typically the final step when checking the validity of a BN254 pairing-based proof.
+
+### Resources
+
+- [P25 Preview examples](https://github.com/jayz22/soroban-examples/tree/p25-preview/p25-preview)
+- [Soroban SDK BN254 documentation - types and functions](https://docs.rs/soroban-sdk/latest/soroban_sdk/_migrating/v25_bn254/index.html)
+- [CAP-74 proposal](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0074.md)
+- [Noir Ultrahonk Soroban Verifier Contract](https://github.com/indextree/ultrahonk_soroban_contract)
+- [Noir documentation (circuits)](https://noir-lang.org/docs/)
+- [Risc0 documentation (circuits)](https://dev.risczero.com/)
+
+## Poseidon
+
+Poseidon is a cryptographic hash function specifically designed for zero-knowledge proof systems, where efficiency inside arithmetic circuits is critical. Unlike traditional hashes such as SHA-256, Poseidon is optimized to minimize the number of constraints required in zero-knowledge circuits by operating natively over finite fields used by zk-SNARKs. This makes it significantly faster and cheaper to prove and verify statements involving hashing, which is why Poseidon is widely used for commitments, Merkle trees, and nullifiers in zero-knowledge applications.
+
+Poseidon host functions support hashing within ZK-friendly environments, but developers must still incorporate them into higher-level proof systems and pair them with Stellar verifier contracts to build end-to-end zero-knowledge application flows.
+
+### Poseidon host functions
+
+- `poseidon` - computes the Poseidon hash of the input field elements
+- `poseidon2` - computes the Poseidon hash of the input field elements
+
+### Resources
+
+- [P25 Preview examples](https://github.com/jayz22/soroban-examples/tree/p25-preview/p25-preview)
+- [Soroban SDK Poseidon documentation](https://docs.rs/soroban-sdk/latest/soroban_sdk/_migrating/v25_poseidon/index.html)
+- [CAP-75 proposal](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0075.md)
+
+:::note
+
+Poseidon is currently being branched out as a separate Rust SDK for use in smart contracts.
+
+:::

docs/build/smart-contracts/overview.mdx

@@ -17,7 +17,7 @@ For a comprehensive introduction to Stellar smart contracts, view the [Smart Con
 
 Write your first smart contract on Stellar using the [Getting Started Guide](./getting-started/setup.mdx).
 
-## Rust on Stellar
+## Developing Smart Contracts
 
 Stellar smart contracts have several characteristics (such as resource limits, security considerations, and more) that force contracts to use only a narrow subset of the full Rust language and must use specialized libraries for most tasks.
 

docs/networks/README.mdx

@@ -61,12 +61,12 @@ Futurenet resets are on a less regular cadence than Testnet resets and don't hav
 
 Testnet resets typically happen once per quarter at 17:00 UTC and are announced at least two weeks in advance on the [Stellar Dashboard](http://dashboard.stellar.org/) and through several developer community channels.
 
-Here are the scheduled 2025 dates:
+Here are the scheduled 2026 dates:
 
-- March 19, 2025
-- June 18, 2025
-- August 14, 2025
-- December 17, 2025
+- March 18, 2026
+- June 17, 2026
+- September 16, 2026
+- December 16, 2026
 
 If you run a Testnet or Futurenet Horizon instance, you need to re-join and re-sync to the network after a reset. Check out how to do that here: [Testnet Reset](https://github.com/stellar/packages/blob/master/docs/testnet-reset.md).
 

docs/tools/developer-tools/online-ide.mdx

@@ -0,0 +1,12 @@
+---
+title: Online IDE
+description: An online IDE for Stellar smart contract development.
+sidebar_label: Online IDE
+sidebar_position: 72
+---
+
+# Online IDE
+
+### [Soropg](https://soropg.com/)
+
+Soropg is an online IDE specifically designed for Stellar smart contract development. It provides a browser-based environment where developers can write, compile, and test Stellar smart contracts without needing to set up a local development environment.

docs/tools/openzeppelin-relayer.mdx

@@ -9,6 +9,10 @@ Launchtube, which served as an experimental service for fee sponsorship and cont
 
 OpenZeppelin Relayer, also known as [Stellar Channels Service](https://docs.openzeppelin.com/relayer/1.3.x/guides/stellar-channels-guide), is a managed infrastructure for submitting Stellar Soroban transactions with automatic parallel processing and fee management. The service handles all the complexity of transaction submission, allowing you to focus on building your application.
 
+## OpenZeppelin Relayer Status
+
+To see live status of the OpenZeppelin relayer, please visit this [Status] page: https://status.channels.openzeppelin.com/.
+
 ## Smart contract invocation
 
 Let’s create a simple application that submits a transaction, invoking a smart contract function, using Relayer. The application calls the Increment smart contract and returns the current counter value.

meetings/2026-01-29.mdx

@@ -18,7 +18,11 @@ This protocol meeting covers CAP-80, which extends Stellar’s BN254 host suppor
 
 ### Key Points
 
-CAP-80: adds BN254 G1 multi-scalar multiplication (MSM), BN254 modular arithmetic host functions, and on-curve checks to improve ZK performance Rationale: reduces expensive guest-side math and avoids repeated point conversion overhead from many add/mul calls Expected impact: major performance gains for contracts using BN254-heavy proving workflows CAP-73 follow-up: enables creating new G-accounts when transferring XLM from Soroban (still requires covering the base reserve) CAP-73 trustlines: proposes an explicit trust(...) function to create missing trustlines when authorized, rather than doing it implicitly during transfers Resources: CAP-80 spec/discussion and CAP-73 spec/discussion links for deeper review
+- CAP-80: adds BN254 G1 multi-scalar multiplication (MSM), BN254 modular arithmetic host functions, and on-curve checks to improve ZK performance
+- Rationale: reduces expensive guest-side math and avoids repeated point conversion overhead from many add/mul calls
+- Expected impact: major performance gains for contracts using BN254-heavy proving workflows
+- CAP-73 follow-up: enables creating new G-accounts when transferring XLM from Soroban (still requires covering the base reserve)
+- CAP-73 trustlines: proposes an explicit trust(...) function to create missing trustlines when authorized, rather than doing it implicitly during transfers
 
 ### Resources