The story, in plain English: what this is for
What is a NAVCoin. A NAVCoin is a new financial primitive: a token whose value tracks the machine-verified net asset value of a real portfolio, the way a fund share tracks a fund, rather than a peg to a dollar. It lets someone turn USDC into exposure to a portfolio and back again, privately, and without trusting an issuer's quarterly PDF, because the backing, the valuation, and the redemption claim are checked by code and tied to the token's supply. It is built to ride the surge in on-chain stocks, commodities, and other tokenized real-world assets: as those assets move on-chain, portfolios of them can be held, swapped, and redeemed the same way. The design is public in the NAVCoin proposal and the private swap explainer.
Who is asking, and for what. Post Fiat runs its own blockchain, where people and AI agents hold and trade NAVCoins. When someone buys into a NAVCoin they pay in dollars, and when they cash out they get dollars back. Those dollars are USDC, and the copy of that USDC that lives on Post Fiat's chain is called pfUSDC. Every pfUSDC is backed one-for-one by real USDC locked in a vault contract on another blockchain, so the pfUSDC vault is the dollar leg of every NAVCoin subscription and redemption. Post Fiat is applying to Circle's Arc Ecosystem Program. The support requested pays for independent security audits of the contracts and proof programs and for running the proof-generating machines as a reliable service; Post Fiat pays for the engineering itself. This page exists because the proposal promised that every claim would be backed by running software, and this is that software, running.
Why Circle would want this. Arc is Circle's own blockchain, and transaction fees on it are paid in USDC. What Circle needs from early builders is real usage rather than farmed activity, and integrations that show what Arc was built for. Post Fiat's offer is to move its USDC vault onto Arc. After that, every time anyone buys into or cashes out of a NAVCoin, real USDC moves into or out of a vault on Arc, with the fee paid in USDC. That is recurring settlement volume tied to asset management, not a one-off demo. The proposal starts with a capped reserve pilot on Arc once the audit clears, a path to moving most of Post Fiat's reserves there, and a public demonstration of an AI agent doing paid work and being paid in USDC on Arc.
Why the zero-knowledge part matters to Arc. A bridge is the software that lets USDC locked on one chain be represented on another. Almost every bridge relies on a small trusted group, a committee or multisig, to say "yes, that deposit happened," and that trusted group is where most of the billions in bridge hacks came from. This bridge is designed to have no such group, and none was involved in the transactions on this page. One caveat, stated in §04: on this test deployment a single administrative key could still bypass the withdrawal check, and removing it is the first job of the audit. Going in, a zero-knowledge proof, a compact piece of math anyone can check, shows that Arc's own validators confirmed the deposit. Going out, a contract on Arc checks a proof that Post Fiat's validators confirmed the withdrawal. That gives Circle two things to talk about: Arc's confirmations can be verified by other chains with math rather than trust, and Post Fiat's validators sign with post-quantum signatures, the kind designed to survive quantum computers, verified inside a proof on Arc. Several of Arc's founding validators are banks and payment networks with active quantum-risk programs; this is a concrete answer for them.
Why the audit is the point. A demonstration on a test network is a demo. The same system, audited by an independent security firm and then run with a capped amount of real money, is a product Circle can point to. The split is simple: Post Fiat brings the working software, and the grant's audit tranches buy the independent review that makes it something institutions can rely on. The rest of this page is what an auditor would start from rather than a pitch: every step tied to a transaction you can look up, 32 deliberately tampered inputs correctly rejected, and the one known weakness stated up front rather than buried (§04). Closing that weakness before real money is at stake is exactly what the audit money is for.
- M1The bridge contracts are deployed and live on Arc's test network.
- M2The proof program for deposits works; 12 tampered deposit inputs were correctly rejected.
- M3 · technical halfOne USDC went Arc → Post Fiat → Arc with both proofs checked on-chain and not an atom lost; 20 tampered withdrawal inputs rejected. This page.
- M3 · audit half → M4Independent audits of the contracts and proof programs, then the capped real-money pilot on Arc and the AI-agent payment demo. This is what the grant funds.
Status of this document. Prepared as the technical basis for Post Fiat's Arc Ecosystem Program application. Nothing here has been audited, reviewed, endorsed, or sponsored by Circle or by any security firm. Arc testnet is alpha software operated by Circle; the PostFiat devnet is a controlled six-validator network. Amounts are testnet USDC.
One open finding qualifies the egress claim on this deployment: the SP1 gateway owner key (EOA 0xdB9b78C8…3814) can admit an unproven withdrawal by registering a permissive verifier under a new selector, because the finality verifier does not pin the proof selector. It is stated in full in
§04, reproduced by a forge test, and its fix is the first item in the audit scope.
01 What was demonstrated
Both directions of the bridge are authorized by succinct proofs of the other chain's finality, verified on-chain. Ingress verifies Arc's Ed25519 commit certificate over the exact block that carries the deposit receipt, plus an EIP-1186 proof of Arc's validator registry at that exact block so the signing set is proven, not assumed. Egress verifies PostFiat's ML-DSA (FIPS-204) consensus certificates inside an SP1 zkVM, wrapped to a constant-size Groth16 proof that an Arc contract checks. There is no attestation layer and no operator checkpoint write. The design intends no signer fallback either; on this testnet deployment that intent is not yet met on egress, because the SP1 gateway owner key can route around the Groth16 check (§04). The transactions below were all authorized by real proofs; the finding is about what the gateway owner could do, and it is what we want audited first.
Everything below ran on real infrastructure on 2 September 2026: a live Arc testnet deposit, an operator-run Arc node for the registry proofs, an A100 for proving, and the six-validator PostFiat devnet with the Arc-capable release deployed through a six-clone deployment gate earlier the same day. Every transaction and contract on this page links to the Arc explorer; every artifact links to the evidence file committed on the branch.
04 Trust model, stated plainly
Ingress (Arc → PostFiat)
Trust is Arc's own consensus: a ≥ ⅔ voting-power quorum of the validator set proven from registry storage at the exact block. A two-thirds collusion of that permissioned cohort could fabricate an ingress fact. Nothing else can: no relayer, no RPC provider (a dishonest provider can only withhold), no operator key.
The registry proof is mandatory even when the set does not change; the guest fails closed without it.
Egress (PostFiat → Arc)
Trust is PostFiat consensus soundness (ML-DSA-65 committee certificates, quorum 5 of 6 on this devnet) plus SP1/Groth16 soundness. The Arc verifier holds a checkpoint that advances only by proof.
Replay is excluded twice: the withdrawal-id commitment and the burn-tx commitment are both consumed on first use.
Privileged controls on this testnet deployment, enumerated
Vault setPaused, held by EOA 0x0995876e5A97C036C0fDa8846F8F47B57B6d2BFc. Liveness only: pause halts deposits and withdrawals; it cannot move funds, alter the verifier, or admit a proof.
SP1 gateway owner(), EOA 0xdB9b78C87F76054b204188109b35cE4614d03814. This is the finding we want reviewed first. The gateway's addRoute reverts RouteAlreadyExists for selector 0x4388a21c, so the owner cannot swap the Groth16 verifier behind today's proofs. The owner can, however, (i) freezeRoute(0x4388a21c), which halts egress (liveness), and (ii) register a route for a different selector to any contract exposing VERIFIER_HASH(). Because PFTLFinalityVerifierV1 forwards proofBytes to the gateway without pinning the four-byte selector, a proof prefixed with such a selector bypasses the Groth16 check. On this testnet that key is therefore a soundness assumption on egress, not only a liveness one. Ingress is unaffected: the PostFiat-side verifier is in-node and governance-pinned.
Reproduced, not just asserted. Four tests in PFUSDCTier4.t.sol deploy the unmodified verifier behind a gateway replica with the exact Arc topology and show: the registered 0x4388a21c route cannot be replaced (RouteAlreadyExists); a forged proof under 0x4388a21c is rejected; freezeRoute halts egress; and, the PoC, a route added under selector 0xdeadbeef lets a bare four-byte "proof" release funds. forge test --root crates/ethereum-contracts --match-contract PFUSDCTier4Test --match-test Gateway.
Mitigation, planned and not yet deployed: the finality verifier binds its immutable sp1Verifier directly to the SP1 v6.1.0 Groth16 verifier at 0xd3b199D0… and rejects any proofBytes whose selector is not 0x4388a21c; the gateway leaves the trust base entirely. The contracts here are immutable, so this is a redeploy of the pair (factory → anchor + vault + verifier), which is why it is scheduled with the audit rather than patched in place. Until then the precise statement is: egress soundness = PostFiat consensus + SP1/Groth16 + non-misuse of the gateway owner key.
Deposits use Arc's transparent path because the proof opens the deposit log.
05 Reproduce and review
Everything is open source at github.com/postfiatorg/postfiatl1v2, branch integrate/arc-tier4-current-v2-20260901. Evidence and source links on this page are pinned to commit 1c136a17 so they cannot drift; the evidence directory is docs/evidence/arc-mvp-20260828/devnet-20260902 (49 files). The claim-classification packet maps every statement in the grant proposal to verified / demonstrated / implemented / planned / aspirational, and the audit scope lists the components, threat model, and deliverables we are requesting. Contracts: crates/ethereum-contracts/src. Guests: programs/pfusdc-arc-ingress, programs/pfusdc-egress. Prover and audit tool: tools/pfusdc-tier4-prover.
# conformance against pinned arc-node source (certificates, receipts, negatives)
cargo test -p arc-conformance --locked
# vault, anchor, factory, finality verifier (22 tests, mock SP1 verifier; 4 of them are the §04 gateway PoC)
forge test --root crates/ethereum-contracts --match-contract PFUSDCTier4Test -vv
# re-run both negative suites against today's witnesses
pfusdc-tier4-prover arc-ingress-audit --witness witness.v2.json --output out.json
pfusdc-tier4-prover egress-audit --witness egress-witness.json --output out.json
# verify today's Groth16 proofs against the pinned vkeys
pfusdc-tier4-prover arc-ingress --witness witness.v2.json --output-dir ./x # executes; --prove to reproduce
What this page does not claim:
- No third-party audit of the contracts or guests has been performed.
- No Arc mainnet deployment exists; chain 5042002 is testnet.
- The PostFiat network here is a controlled devnet, not a public mainnet.
- Egress on this deployment is not yet free of administrative keys; the gateway-owner finding in §04 stays open until the verifier is redeployed with a direct binding.
- “First” claims, TVL forecasts, and operating cadence are commercial statements outside this packet.
Post Fiat