ProofBridge smart contract reference and addresses

Explore the four ProofBridge contracts, their key functions, deployed addresses on Ethereum Sepolia and Stellar Testnet, and the EIP-712 order structure.

ProofBridge settles cross-chain transfers entirely on-chain through four contracts deployed on each supported network. Two of these — AdManager and OrderPortal — are the contracts you interact with directly. The other two — MerkleManager and Verifier — operate in the background to record order history and validate zero-knowledge proofs.

Contracts at a glance

AdManager

Where Makers create and manage liquidity ads, lock funds against orders, and receive settlement after a successful transfer.

OrderPortal

Where Bridgers initiate cross-chain transfers by depositing source-chain tokens and creating a signed order.

MerkleManager

An append-only Merkle Mountain Range that permanently records every order hash. You never call this contract directly.

Verifier

Validates zero-knowledge proofs on-chain using the UltraHonk proving system. You never call this contract directly.

---

AdManager

AdManager is deployed on the destination chain — the chain where the Maker’s liquidity lives and where the Bridger’s funds will be released. As a Maker, all your day-to-day activity happens here.

What you can do

Function	Description
createAd	Post a new liquidity advertisement with a specific token and amount.
fundAd	Deposit additional tokens into an existing ad to increase available liquidity.
withdrawFromAd	Withdraw unused tokens from an open ad.
closeAd	Permanently close an ad and recover all remaining funds.
lockForOrder	Reserve liquidity against a specific EIP-712 order hash. This appends the order to the chain’s Merkle tree.
unlock	Submit a ZK proof to complete settlement. Releases the locked ad token to the Bridger’s designated recipient.

Only the relayer calls unlock on your behalf after a valid ZK proof is generated. You do not need to call it manually.

---

OrderPortal

OrderPortal is deployed on the source chain — the chain where a Bridger deposits the tokens they want to transfer. Bridgers interact with this contract when they create an order.

What you can do

Function	Description
createOrder	Deposit source-chain tokens and open a cross-chain order. The order hash is appended to the chain’s Merkle tree.
unlock	Submit a ZK proof to release the deposited tokens to the Maker’s designated recipient on this chain.

As with AdManager, the relayer calls unlock on your behalf. After you create an order, the protocol handles the rest automatically.

---

MerkleManager

MerkleManager maintains a Poseidon2-based Merkle Mountain Range (MMR) — an append-only ledger of every order hash ever created on the chain. It is a foundational piece of the security model: a proof of deposit on Chain A must include a valid Merkle inclusion proof against Chain A’s MMR root.

You do not call MerkleManager directly. AdManager and OrderPortal hold the MANAGER_ROLE permission to append hashes after each deposit or lock.

---

Verifier

Verifier stores the verification key on-chain and validates the UltraHonk zero-knowledge proofs submitted during settlement. It uses the BN254 elliptic curve and a keccak-based Fiat-Shamir transform for efficient on-chain verification.

You do not call Verifier directly. AdManager and OrderPortal call it internally during each unlock.

The Soroban side delegates the inner verification loop to the open-source rs-soroban-ultrahonk crate, which calls Soroban’s native BN254 host functions (env.crypto().bn254().g1_msm, env.crypto().bn254().pairing_check) for every elliptic-curve operation. The full implementation walkthrough — host functions, verifier pipeline, SRS, and VK immutability — lives in the Soroban verifier internals reference. The EVM side uses Ethereum’s ecMul / ecAdd / ecPairing precompiles via an auto-generated Solidity verifier (contracts/evm/src/Verifier.sol) consuming the same proof bytes against the same VK.

---

Deployed addresses

Canonical sources of truth: the deployment manifests at contracts/evm/deployments/11155111.json and contracts/stellar/deployments/1000001.json in the monorepo. The tables below are snapshots; if they ever drift from the manifests, the manifests win.

Ethereum Sepolia

Chain ID: 11155111

Core contracts:

Contract	Address
Verifier	0xdD0aF03aF86923F3c4896f5895604893281B0D23
MerkleManager	0x8316caaC87BDe7622d33a4d3A94e392dc6F5277b
AdManager	0xe56bc3fE43edb738a90639695639aD0711Df65D9
OrderPortal	0xFC9e524dF436d3bA3B22C1C29058327c54B6f75d
wNativeToken (WETH)	0x38F67Fb97B96988B9d5Ef3f0f9E0DB924780D1ef

Bridged tokens:

Token	Symbol	Address
Wrapped XLM	WXLM	0xba033066076e704E50124B9cDba63EFD3dC6414c
Native Ether (sentinel)	ETH	0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
ProofBridge test token	PB	0x407498fD9C955bed021c03BcbB99aD514042b59B

Stellar Testnet

Chain ID: 1000001  ·  Network passphrase: Test SDF Network ; September 2015

Soroban contract IDs are strkeys — base32-encoded 56-character identifiers starting with C.

Core contracts:

Contract	Contract ID
Verifier	CBK5UOQDTK4CKD4XKCLMBQOYN26EOH2RT5K2UFL7XUF33DRI3KIELUS4
MerkleManager	CDNR5ST4SMVBZQKHSLQZ7ROHSOAVRCYMFA76I3MT5Z6ZTVFGT4CSWBN2
AdManager	CAP3YYF4WDEQME44GP7UNLZVHMAUB7L2DYLXUPWBD43Y72QBCB6PX65A
OrderPortal	CCRGG44MLSK46BHQLZZMTKDQAA6Y54XQPKIVJLEW5DF4JV7BOCAWXIIA
wNativeToken (wrapped XLM)	CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC

Bridged tokens:

Token	Symbol	Contract ID
Stellar XLM (native, via wrapper)	XLM	CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC
Wrapped ETH (SEP-41)	wETH	CB73XXFFMBNAVYCFC6I2MRIMWSCQRCMIG2TCQVJYTUDHVPTL53IHJVLM
ProofBridge test token (SEP-41)	PB	CC2RCWFXWYZJ7R75G7DM7Z2SDQQH3MWETCFBKUY27OCUXAYPGERWJJIS

---

The Order struct (EIP-712)

Every cross-chain transfer is represented as a typed EIP-712 struct. Signing this struct cryptographically binds your order to the specific chains and contracts involved — it cannot be replayed on a different chain or with a different contract.

The domain separator uses:

• Name: Proofbridge
• Version: 1

The chain ID and contract addresses are explicit fields in the struct itself, rather than in the domain, ensuring every field is visible and auditable — and critically, ensuring both chains produce the same digest for the same order. See Order hashing for the full treatment.

Order {
  orderChainToken     // token you are depositing (source chain)
  adChainToken        // token you will receive (destination chain)
  amount              // transfer amount, in order-chain raw units
  bridger             // your address as the Bridger
  orderChainId        // source chain ID
  orderPortal         // OrderPortal contract address on the source chain
  orderRecipient      // address to receive funds on the source chain (Maker's payout)
  adChainId           // destination chain ID
  adManager           // AdManager contract address on the destination chain
  adId                // identifier of the Maker's liquidity ad
  adCreator           // Maker's address
  adRecipient         // address to receive funds on the destination chain (your payout)
  salt                // caller-controlled nonce to prevent duplicate orders
  orderDecimals       // uint8 — decimals of the order-chain token (see Decimal scaling)
  adDecimals          // uint8 — decimals of the ad-chain token
}

Never reuse a salt value. Each order must have a unique salt to produce a distinct order hash. Reusing a salt with the same parameters will cause the transaction to revert.

Related references

• Decimal scaling — how orderDecimals / adDecimals rebase the amount across chains, and the errors that catch a mismatch.
• Recipient address invariants — per-chain encoding rules for orderRecipient / adRecipient (EVM upper-bytes zero, Stellar Ed25519-only).
• Off-chain signing — the TS recipe for reproducing the on-chain digest and pre-auth request hashes bit-for-bit.