Loading...
Supporting developers, startups, and full-fledged companies building on Stellar and Soroban
© 2025 Stellar Development Foundation
Subscribe to the Newsletter
By ProofBridge (P2P ZK Cross Chain Bridge)
ProofBridge is a peer-to-peer cross-chain bridge secured by zero-knowledge proofs. A maker (liquidity provider) and a bridger (user) are matched directly on each trade. Each side's funds stay in protocol-controlled escrow on their own chain. Funds release only when an on-chain ZK proof confirms the deposit on the counterpart chain.
- Zero-knowledge proofs
This bridge is a verification protocol, not a privacy protocol. Order amounts, recipient addresses, chain IDs, and Merkle roots are public on-chain. The "zero-knowledge" label is a mathematical property of the proving system; what ProofBridge uses is the succinctness of those proofs — a short certificate one chain can verify cheaply, attesting that a specific deposit tied to an order was correctly recorded on the other chain.
Each chain is a closed world: Where alternating chains cannot read each others state, for example Stellar cannot read Ethereum's state and Ethereum cannot read Stellar's. The conventional fix is a trusted authority. ProofBridge replaces this authority with the proof. The destination chain accepts the proof as cryptographic evidence of the source-chain deposit; if the proof doesn't verify, no funds move.
- Merkle Mountain Range (the cross-chain ledger)
Each chain stores every order hash in an append-only on-chain structure called a Merkle Mountain Range. The MMR's current state is a single short root, published on-chain after every deposit. Both chains use the same MMR construction and the same hash function (Poseidon2), so both chains compute identical roots for identical inputs.
At settlement, the proof checks that a specific order hash is included under a specific MMR root. The destination chain reads the source chain's published root, verifies the proof against it, and treats the result as evidence of the deposit. Forging a proof for an order that isn't in the tree is computationally infeasible as there's no valid inclusion path to construct.
Cross-chain bridges typically share three structural trade-offs: funds flow through a central pool, an external validator set approves transfers, and users wait for off-chain consensus.
Validator-based bridges have broad chain coverage today, but every transfer routes through guardians or oracles or centralized authorities that must sign off — a trust assumption and an attack target. ProofBridge's only signers on a trade are the two parties on it.
Full feature-by-feature comparison against other cross chain bridges: docs.pfbridge.xyz/concepts/comparisons
This funding takes ProofBridge from a working testnet bridge to a trustless mainnet protocol. We will build three things:
1. BLS counterparty consensus
Both parties sign the EIP-712 order digest once with a BLS12-381 key. The two signatures aggregate into a single G1 point. One pairing check on each chain replaces the current pre-authorization relayer.
How Stellar is used:
Soroban native pairing primitive (env.crypto().bls12_381().pairing_check, CAP-0059) for on-chain BLS verification.
BN254 UltraHonk verifier (already in production) continues gating the deposit proof. The BLS layer sits on top of it for counterparty consent.
Standalone Noir BLS auth circuit using the noir_bls12_381_pairing library, ships as a building block for off-chain agent attestations.
New BLSKeyRegistry Soroban contract maps each Stellar account to its BLS public key, with Proof-of-Possession enforced at registration.
Impact: the manager-key relayer is removed. Once both parties sign, anyone can submit the unlock. The relayer is no longer a permissioned actor, and ProofBridge becomes truly permissionless on the unlock path.
Each maker deploys their own custom-account contract on Soroban (__check_auth). Agents act on behalf of the maker, but only inside a policy table the maker controls — per-order cap, daily volume cap, token whitelist, expiry, revocation. The maker's wallet key never leaves the maker. A bonded dispute path (dispute → respond → resolve) handles contested trades. A permissionless cancel path handles stuck trades after deadline.
How Stellar is used:
Soroban __check_auth host hook for custom accounts. EVM emulates this via Safe modules; on Stellar it is a host primitive.
Multi-key BLSKeyRegistry v2 with stable monotonic slot IDs. Makers rotate agent keys in a single transaction without closing ads.
Pull-payment escrow pattern on all dispute payouts.
Impact: makers can run automated liquidity operations without giving up custody. Stuck or contested orders have on-chain recovery paths instead of manual support tickets and resolution is cancellation of trades.
Audit-gated production deployment on Stellar Mainnet + Ethereum Mainnet. Launch route: USDC (ERC-20) ↔ USDC (Stellar SAC) between Circle's existing token contracts on each chain. ProofBridge does not issue tokens. Routes are config on top of unmodified third-party assets.
How Stellar is used:
Stellar Asset Contract (SAC) for Circle USDC on the Stellar side.
24-hour timelock on every fund-touching admin operation on both chains.
5-of-7 ArbiterRole multisig for dispute resolution (3 team + 4 ecosystem signers sourced via the Stellar Foundation). A 5-of-7 quorum from a 3+4 pool means every dispute decision needs at least 2 non-team signatures.
5-second finality and sub-cent fees keep the 0.5% bridge fee viable at small ticket sizes.
Cross-chain reconciliation listener (read-only) watches both chains for settlement discrepancies within a 5-minute SLA.
Impact: ProofBridge ships to mainnet on Stellar's stack. New routes (RWA, additional stablecoins, native-token wrappers from ecosystem partners) are config-only admin calls.
Production launch on Circle's existing USDC contracts (ERC-20 on Ethereum, SAC on Stellar).
A two-sided market needs both sides on day one. We seed maker-side liquidity ourselves at launch, running team-operated maker accounts using the same auto-merchant pattern already running on testnet, so the first mainnet bridger meets a working order book instead of an empty one. Public maker recruitment opens once cumulative volume crosses the threshold where third-party LPs clear cost basis from the 0.3% LP fee. We will publish a maker-onboarding guide alongside the SDK so independent operators can run their own ad accounts under the scoped-agent model from T2.
In-wallet discovery. ProofBridge's frontend integrates with Stellar Wallets Kit (Freighter, Lobstr, xBull, Hana, Albedo, Rabet) and RainbowKit on the EVM side. Anyone holding Stellar USDC who wants EVM-side exposure (or the inverse) lands on app.pfbridge.xyz from a wallet they already use.Post-launch outreach to wallet teams targets featuring ProofBridge as
their cross-chain rail.
Developer integrations. The TypeScript SDK + OpenAPI spec (T3.4) and the reference integration walkthrough (T3.8) make ProofBridge embeddable. Aggregators and dApps that need a Stellar ↔ EVM rail can plug it in with typed client calls. Engineering-led outreach alongside T3.8 targets the first 1–2 ecosystem integrations.
Stellar Foundation visibility. ArbiterRole signer recruitment (T3.1) is a structural partnership with SF and ecosystem signers — the same conversations create visibility for ProofBridge as a Stellar-native cross-chain primitive.
- Route expansion via asset partnerships (post-launch)
Adding a route requires the asset to exist on both chains; we don't issue tokens. Post-launch outreach focuses on Stellar-native RWA issuers (tokenized treasuries are the obvious first target) and additional stablecoin issuers. Each new pairing becomes a timelocked admin call (set_token_route + set_settlement_window + set_bond_config) once the counterpart asset is live — the partnership is the gating work, not the protocol change.
Sustainability:
The protocol is fee-supported at mainnet from day one. The 0.5% total bridge fee splits 0.3% to the maker LP and 0.2% to the protocol fee pool; the bridger nets 99.5% of the destination amount. Both percentages are timelocked admin parameters capped at 1% in contract.
Compliance is a mainnet-readiness workstream for ProofBridge. Our approach is permissionless core, compliant perimeter: the base contracts remain non-custodial and open, while the parts we operate — including the frontend, SDK, hosted services, monitoring systems, and Maker onboarding flows — receive safeguards before mainnet.
The compliance framework is organized around four core areas:
Frontend access controls
AML/KYT wallet-risk screening
Suspicious activity monitoring
Maker/liquidity-provider expectations
At the frontend level, we plan to implement counsel-reviewed Terms of Service and Acceptable Use Policies, geofencing for sanctioned/restricted jurisdictions, wallet-level blocking for sanctioned or clearly high-risk addresses, wallet-risk checks before transaction signing, decision logging, and a false-positive appeal path. The frontend will also clearly state that it is an interface to non-custodial software, not a custodial exchange.
For AML/KYT screening, both source and destination wallets will be evaluated through a sanctions and wallet-risk provider before orders are created or accepted through the official interface. Screening will include OFAC/EU/UK/UN sanctions exposure, mixer exposure, hacked-funds clusters, ransomware indicators, darknet-market exposure, and other illicit-risk signals. We are evaluating providers such as Range, TRM Labs, Chainalysis, and Elliptic, with final thresholds and policies to be defined alongside external compliance advisors before mainnet.
ProofBridge is structurally different from privacy-mixer systems. The ZK proof verifies that a valid source-chain action occurred before settlement, but does not hide recipients, amounts, order hashes, or settlement flows. This preserves auditability and provides a strong base for retrospective monitoring and forensic review. Before mainnet, we plan to implement monitoring around suspicious patterns such as structuring, unusual cross-chain routing, rapid wallet movement, repeated disputed orders, sudden Maker volume spikes, or compromised liquidity-provider behavior, with documented review and escalation processes around the official interface and hosted services.
For Makers and liquidity providers, we plan to publish a Maker Code of Conduct and work with external legal/compliance experts to define material-volume thresholds and tiered review expectations. The current direction includes self-attestation above defined thresholds, KYC for individual professional Makers where appropriate, KYB for entity/institutional Makers where appropriate, and frontend curation controls so bad actors can be removed from the official interface while the base contracts remain open. We are also evaluating SEP-12-style credentialing approaches and providers such as Sumsub, Persona, and Onfido for optional credentialed Maker lanes.
We are not positioning ourselves as in-house legal experts. Part of this grant plan is to engage crypto-specialized counsel, a KYT/sanctions-screening provider, and a fractional compliance advisor before mainnet so the final framework is professionally reviewed and aligned with the jurisdictions and liquidity routes we support.
Full information: Compliance
$150.0K
ProofBridge is a working testnet bridge today. All claims below are verifiable on-chain or via public URLs.
Live infrastructure (Sepolia + Stellar Testnet):
App: app.pfbridge.xyz
Marketing site: pfbridge.xyz
Backend API: api.pfbridge.xyz
Docs: docs.pfbridge.xyz
Deck: ProofBridge Deck
Repo (public monorepo): github.com/Explore-Beyond-Innovations/ProofBridge
Two active bridge routes wired end-to-end on testnet
(the full create order → MMR append → ZK proof → unlock cycle completes on both chains):
PB (Sepolia) ↔ PB (Stellar) — ProofBridge test-token pair (test ERC-20 on EVM, custom Soroban SEP-41 on Stellar) for end-to-end integration testing
XLM (Stellar) ↔ wXLM (Sepolia) — auto-wraps native XLM into a ProofBridge wrapped-native contract on the Stellar side and an ERC-20 on the Sepolia side
The bridge is open for community testing today; deeper public bridging traffic and a 14-day soak ship as part of T2.
Deployed contracts.
Full address index for both chains (Stellar Testnet + Ethereum Sepolia), the EIP-712 Order struct, and decimal-scaling rules: docs.pfbridge.xyz/reference/smart-contracts.
Noir UltraHonk deposit proof in production.
Public inputs: [nullifier_hash, order_hash_mod, target_root, ad_contract_flag]. Generated proofs settle on-chain via auto-generated Soroban + Solidity verifiers.
Cross-chain digest invariant.
Single 15-field Order struct (including orderDecimals / adDecimals) with EIP-712 domain name="Proofbridge", version="1" and chainIds + contract addresses inside the struct. The orderHash is byte-identical on both chains by construction — one ZK proof settles both sides.
Auto-merchant bot operational on testnet.
A polling service that auto-locks incoming orders against the testnet admin wallets so that new testnet bridgers never hit a "no merchant answered" dead end. This is the service that gets refactored under the Soroban custom-account agent model.
This tranche retires the pre-authorization relayer and ships BLS-only counterparty consensus on testnet. It also bundles several defensive contract changes in the same migration: pull-payment escrow on unlock paths, route-commitment per ad, leaf-side MMR binding (closes the X-1 attack surface), pause primitive on every state-changing entry point, two-step admin transfer, and event emission on every admin write.
Total: $30,000 (20% of grant).
Estimate: 6 weeks
Description: Greenfield Noir circuit using the noir_bls12_381_pairing library, leveraging existing ecosystem tooling rather than reimplementing hash-to-curve from scratch. Verifies an aggregated maker + bridger BLS12-381 signature over the EIP-712 order digest, producing a UltraHonk proof.
How to measure completion: Circuit compiles under UltraHonk and verifier auto-generation succeeds for both Soroban and Solidity. Proof generation completes in ≤30 seconds on a reference 8-core / 16 GB machine. Test pack of 4 cases — valid aggregate, single-signer aggregate (degenerate), invalid signature rejection, wrong-pubkey rejection — all pass. Public circuit source committed to proof_circuits/auth/.
Budget: $9,000
Description: New BLSKeyRegistry contract on each chain (Soroban + Sepolia Solidity) maps each wallet to a registered BLS public key, with Proof-of-Possession enforced at registration. Wires the pairing-check call into both AdManager.unlock and OrderPortal.unlock.
How to measure completion: BLSKeyRegistry deployed on both testnets with public contract addresses. AdManager.unlock and OrderPortal.unlock accept aggregated BLS signatures and reject malformed/incorrect ones (4 negative-path tests per side). Pairing check executes on Soroban testnet in <2 seconds wall-clock. Re-registering a key without a fresh PoP signature reverts.
Budget: $7,500
Description: Bring proof generation back from the current ~1-minute regression (after the in-house MMR rebuild) to **<**30 seconds on a reference machine via algorithmic and Noir-witness changes.
**How to measure completion: <**30 seconds for proof generation on 8-core / 16 GB reference benchmark. Regression test in CI guarding the new performance bound. Existing UltraHonk verifier accepts new proofs unchanged.
Budget: $3,500
Description: Update app.pfbridge.xyz for the new co-sign UX: route discovery, maker + bridger signing prompts, aggregated-signature submission flow, status tracking through the new path.
How to measure completion: All BLS-flow user states reachable from the production frontend. 4 user roles tested (Maker, Bridger, observer, admin). Stellar Wallets Kit + RainbowKit BLS-key registration flow live for both chains. 0 broken flows on a 10-step end-to-end QA script.
Budget: $5,000
Description: Refactor the NestJS backend to remove the pre-auth signing code path. Backend collapses to a stateless aggregator that collects signatures and submits aggregates; anyone can run the same code.
How to measure completion: _consumeAuth, managers[], requestTokens[], and the signature / authToken / timeToExpire parameters removed from every state-changing entry point on both chains. Backend rebuilds and integration tests pass on the BLS-only path. README + architecture doc updated to reflect the stateless aggregator model.
Budget: $3,500
Description: End-to-end test pack covering both directions of bridging through the new BLS-only flow, plus a public demo recording for SCF reviewers.
How to measure completion: Cross-chain demo video published showing ≥10 end-to-end testnet bridge transactions through the BLS-only flow. Integration test pack passing in CI on every PR. Demo URL + tx hashes referenced in the T1 milestone submission.
Budget: $1,500
Tranche #1 Success Criteria
Pre-auth path retired across both chains (_consumeAuth, managers[], requestTokens[] all removed)
BLS-only flow live on Stellar Testnet + Sepolia; ≥10 end-to-end testnet bridges executed through it
MMR proof generation back to <30 seconds on the reference machine
Pairing check on Soroban testnet under 2 seconds wall-clock
Public BLS-flow demo recording + cross-chain integration test pack passing in CI on every PR
This tranche adds Soroban custom-account agents under scoped policy, an end-to-end dispute resolution lifecycle (with permissionless cancel-after-deadline), and a 14-day public testnet soak.
Total: $45,000 (30% of grant).
Estimate: 6 weeks
Description: Greenfield __check_auth custom-account contract per maker. Stores a policy table per agent: allowed actions, token whitelist, per-order cap, daily volume cap, expiry, revocation flag. Owner-only set_policy and revoke_agent.
How to measure completion: Custom-account contract deployed to Stellar Testnet with public contract address. All 4 policy enforcement paths covered by integration tests (cap exceeded, token not whitelisted, expired, revoked). revoke_agent instant-kill switch verified mid-trade. Owner-only access control: non-owner set_policy calls revert.
Budget: $11,000
Description: Refactor the existing auto-merchant-bot from the testnet manager-key model to the scoped agent-account model. Bot becomes a process running under a constrained on-chain authority.
How to measure completion: Bot runs against agent-account authorization on testnet (no manager-key fallback path). Agent rotation tested: in-flight orders survive a key rotation in BLSKeyRegistry v2 without close-and-recreate. Bot service re-deployable with a new agent identity in <10 minutes via documented runbook.
Budget: $9,000
Description: Full design and implementation of the dispute lifecycle on both chains. States: Open → Disputed → Resolved, plus the Open → Cancelled path after deadline. Outcomes: MutualRefund, TradeProceeds, BridgerForfeit, MakerForfeit.
How to measure completion: Dispute spec published at docs.pfbridge.xyz/architecture/phase-3-agents-disputes. All 4 dispute outcomes implemented and tested on both chains (8 integration tests total). Bond posting and return tested on each outcome. Pull-payment escrow pattern verified for all payout paths.
Budget: $11,000
Description: UI for dispute filing, evidence submission, response submission, and arbiter-resolution tracking. Plus the post-deadline cancel-and-refund flow.
How to measure completion: Dispute filing flow functional from the live testnet frontend. All 4 dispute outcomes visible in the user dashboard with auditable trail. Cancel-after-deadline flow exercises end-to-end on testnet for both cancel_order and cancel_lock.
Budget: $4,500
Description: Cross-component test suite covering chaos scenarios — agent compromised mid-trade, dispute raised against an agent-issued lock, double-disputes, deadline race conditions.
How to measure completion: Test pack covers 8 chaos scenarios (4 agent compromise + 4 dispute edge cases), all passing in CI. Test pack publicly documented with reproduction steps in the repo.
Budget: $4,500
Description: 14-day public soak with the new agent + dispute model live on testnet. Public proof + dispute dashboard tracking ongoing activity.
How to measure completion: 14-day public soak completes without rollback. ≥3 distinct agent accounts deployed by independent testnet operators during the soak window. ≥50 end-to-end bridge transactions completed. ≥2 dispute lifecycles exercised end-to-end (different outcome classes). Public dashboard live at dashboard.pfbridge.xyz with transactions, dispute outcomes, and proof-gen latency on rolling 30-day data.
Budget: $5,000
Soroban custom-account agent contract live on testnet; all 4 policy enforcement paths covered by integration tests
Multi-key BLSKeyRegistry v2 rotates agent keys in a single transaction without closing ads
Dispute lifecycle implements all 4 outcomes (MutualRefund, TradeProceeds, BridgerForfeit, MakerForfeit) end-to-end on both chains
Permissionless cancel-after-deadline path tested on both AdManager and OrderPortal
14-day public soak: ≥3 independent operators, ≥50 bridge transactions, ≥2 dispute lifecycles resolved
Public proof + dispute dashboard live with rolling 30-day data
This tranche audit-gates the protocol and ships to Stellar Mainnet + Ethereum Mainnet over a single launch route — USDC ↔ USDC. Multisig admin + 24h timelock active on both chains; 5-of-7 ArbiterRole multisig with ecosystem signers sourced via the Stellar Foundation; cross-chain reconciliation listener watching both chains; audit-medium remediation, compliance-readiness implementation, a reference SDK integration walkthrough, and a public performance benchmark close out the tranche.
Total: $60,000 (40% of grant). Stellar Audit Bank credits gate this tranche per SCF rules; audit costs are not part of this ask.
Estimate: 6 weeks
Description: Three new contract changes ship on both chains: an operational 24-hour timelock wired into every fund-touching admin function (with a one-shot bootstrap bypass for initial config); a protocol fee mechanism that deducts the 0.5% bridge fee destination-side and splits it 0.3% to the maker LP / 0.2% to the protocol fee pool; and per-route bond configuration so dispute bonds scale with order size in the route's own token. Then the full T1 + T2 + T3 contract suite deploys to Stellar Mainnet and Ethereum Mainnet, validated against mainnet-fork tests on real-state forks. Admin transfers to a multisig on each chain, a separate 5-of-7 ArbiterRole multisig comes online, and the timelock activates.
How to measure completion: Mainnet contract addresses publicly listed at docs.pfbridge.xyz/reference/smart-contracts. Admin multisig holds the admin role on both chains (Stellar account-level multi-sig + Gnosis Safe on EVM). 5-of-7 ArbiterRole multisig active with ≥2 non-team signers in any decision by construction. 24-hour timelock active and tested on ≥3 admin operations (route change, fee parameter change, role grant). Mainnet-fork test suite passing — timelock invariants, fee-accounting identity, bond ladder math.
Budget: $13,000
Description: Build out the multi-region failover topology, observability instrumentation (custom metrics, alerting rules, on-call paging integration), database replication setup, and the deployment + incident runbook.
How to measure completion: HA architecture document published with topology diagram and failover steps. Custom Prometheus / OpenTelemetry instrumentation merged into the backend with ≥10 named metrics around proof submission, unlock latency, and reconciliation lag, and KYT/screening flow observability. Alert rules deployed for the 5 critical paths (deposit-detect, proof-gen, unlock submission, reconciliation, dispute trigger). Deployment runbook merged into the repo with rollback procedure; primary/standby failover exercised in a staged drill.
Budget: $11,000
Description: Configure the USDC ↔ USDC route on both chains via timelocked admin calls (Circle's existing ERC-20 on Ethereum and SAC on Stellar — both contracts unmodified by ProofBridge; no token issuance). Bootstrap maker-side liquidity from ProofBridge-operated maker accounts. Run the first-tx ceremony end-to-end in both directions and document publicly.
How to measure completion: USDC route registered via set_token_route on both chains. First-tx ceremony executed Ethereum→Stellar and Stellar→Ethereum; tx hashes + contract addresses recorded at docs.pfbridge.xyz/reference/smart-contracts. Reconciliation listener verifies both directions settled cleanly within the 5-minute SLA window. Initial maker liquidity sized to support an opening trade range without depleting on the ceremony.
Budget: $3,000
Description: Typed TypeScript SDK published to npm with typed clients for backend, Stellar, and EVM contract surfaces; BLS sign helper; aggregator client with retry/backoff and exponential jitter; ESM + CJS dual export. OpenAPI spec auto-generated from NestJS decorators with stable /v1/* route prefix, rate limits per IP / API key, partner API keys, CORS allowlist. Three example projects in a separate examples repo: a browser bridge UI (MetaMask + Freighter), a maker-bot reference, and a read-only order monitor.
How to measure completion: @proofbridge/sdk v1.0.0 published to npm with type definitions for all bridge operations and CI-driven release on tagged versions. api.pfbridge.xyz/openapi.json live and validated against the running backend; Swagger UI at /docs. ≥3 example projects in github.com/Explore-Beyond-Innovations/proofbridge-examples. API contract tests passing in CI on every PR.
Budget: $10,000
Description: Standalone service with stellar-watcher (Soroban events) and ethereum-watcher (logs subscription) feeding a correlator that maps orderHash → state across chains. Detects four discrepancy classes — source-only Filled, destination-only Filled, mismatched fill amounts, stale Disputed — and alerts via PagerDuty + a public read-only dashboard. Private RPC tier on both chains (paid provider primary + secondary fallback) with health-check failover and last-seen-block checkpointing in Redis for event replay on reconnect. Read-only — no on-chain authority. Compliance-monitoring hooks will also support retrospective review of suspicious routing patterns, repeated failed/disputed orders, and abnormal Maker activity around official services.
How to measure completion: Service running 24/7 across two regions. ≥99.9% uptime over the post-launch window. All injected discrepancies caught within ≤5 minutes in chaos tests. Replay-on-reconnect verified after a simulated outage of >10,000 Ethereum blocks / >24h Stellar ledgers. Public dashboard at status.pfbridge.xyz showing settlement-success rate + most recent reconciliation cursor per chain + discrepancy log.
Budget: $9,000
Description: Full mainnet docs: deployed addresses, SDK getting-started guide, integration partner onboarding section, security model with the BLS-end-state framing, and compliance/AML/KYT documentation covering frontend controls, wallet-risk screening, Maker expectations, monitoring flows, and external compliance engagement plans.
How to measure completion: docs.pfbridge.xyz/reference/smart-contracts lists every mainnet address. docs.pfbridge.xyz/guides/integrate-the-sdk covers SDK init, bridge initiation, status polling, and webhook setup with ≥3 code snippets. docs.pfbridge.xyz/reference/security-model covers the BLS aggregate + ZK + nullifier + EIP-712 binding gate stack with mainnet trust assumptions (multisig, timelock, ArbiterRole).
Budget: $5,000
Description: Close all medium findings from the Stellar Audit Bank engagement (critical/high are closed during the audit gate pre-deploy). Each finding tracked publicly, with remediation merged and verified on mainnet contracts.
How to measure completion: All medium findings from the Audit Bank engagement closed and merged. Public GitHub project board lists one issue per finding linked to its remediation PR; each PR includes the auditor's restatement of the issue and the fix's verification on mainnet.
Budget: $5,000
Description: Publish a reference wallet/aggregator integration end-to-end using the ProofBridge SDK. Include a clonable working repo a developer can run, code samples for each integration step, and screenshots of the resulting bridge flow.
How to measure completion: Walkthrough published at docs.pfbridge.xyz/guides/ covering wallet connect, route listing, order creation, status polling, and unlock retrieval. Companion repo under github.com/Explore-Beyond-Innovations/proofbridge-examples/ with a runnable example a developer can clone and execute against testnet or mainnet.
Budget: $3,000
Description: Run a load test against the live mainnet USDC route under nominal traffic and publish the methodology + results.
How to measure completion: Public benchmark report at docs.pfbridge.xyz/reference/ showing end-to-end bridge time on the USDC route under nominal mainnet load. Target: ≤2 minutes p50, ≤5 minutes p95. Methodology, concurrency profile, and raw measurements included for reproducibility.
Budget: $1,000
Public compliance documentation published covering sanctions screening, Maker expectations, monitoring flows, and escalation processes
All 5 contracts (AdManager, OrderPortal, MerkleManager, Verifier, BLSKeyRegistry) live on Stellar Mainnet + Ethereum Mainnet
USDC ↔ USDC route operational; first-tx ceremony executed in both directions with public tx hashes
Admin multisig + 24-hour timelock + 5-of-7 ArbiterRole active on both chains, with ≥2 non-team signers in every dispute decision
Cross-chain reconciliation listener detecting settlement discrepancies within ≤5 minutes
TypeScript SDK published to npm; OpenAPI spec live at api.pfbridge.xyz/openapi.json
Within 30 days of mainnet launch: ≥100 successful mainnet bridge transactions on USDC ↔ USDC, ≥99.5% transaction success rate, ≤2-minute p50 bridge time, ≥10 unique mainnet bridger addresses
ProofBridge is built under the Explore-Beyond-Innovations team.
Joseph Edoh, Blockchain Developer (~CEO)
4 years in blockchain development. Ex-OnlyDust Starknet Fellow and active open-source contributor across multiple ecosystems. Leads the Contract suite development, the Noir ZK proof circuits, and the cross-chain protocol design.
LinkedIn: linkedin.com/in/joseph-edoh-02b30a18a
GitHub: github.com/JoE11-y
Ugonna Dike (~COO)
Community builder with 3 years in open source, focused on contributor support, community operations, and developer-ecosystem growth. Community Lead at Drips and former Community manager at OnlyDust. At ProofBridge, leads product strategy, partnerships, and program operations.
LinkedIn: linkedin.com/in/ugonna-dike-a57182189
GitHub: github.com/Ugo-X
Osaretin Frank, Fullstack Developer (~CTO)
Has won a couple of Stellar hackathons. 5+ years building enterprise software, 2+ on EVM chains and Solana. Drives ProofBridge's UI and user-experience across the app.
LinkedIn: linkedin.com/in/osaretin-frank-osariemen-03047a1a6
GitHub: github.com/osas2211
Isaac Ugwu, AI & Software Engineer (~RAW)
3+ years building payment rails and AI systems. Drives ProofBridge's AI automation layer, work that turns routine liquidity operations into agent-driven flows on Soroban's custom-account model (anomaly detection, adaptive fee setting, predictive liquidity provisioning, and agent co-pilots inside scoped on-chain authorisation).
LinkedIn: linkedin.com/in/onyemaechi
GitHub: github.com/dprof-in-tech
Isaac Onyemaechi Ugwu
UGONNA PAUL DIKE
Joseph Edoh
Osaretin Frank Osariemenn
No other submissions.