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 for $250,000 in four milestone-locked payments, and is proposing that the security firm Zellic join as co-applicant and independent auditor. Zellic has not yet agreed to this; this page is the material we are putting in front of them to decide. The money pays for independent security audits 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 $500,000 reserve 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 a co-application with Zellic would make sense. 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 proposed split is simple: Post Fiat brings the working software, the auditor brings the review that makes it something institutions can rely on, and the grant's audit tranches pay for that review. If Zellic takes this on, the rest of this page is the evidence they 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 (proposed: Zellic), 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 basis for a proposed co-application with Zellic, who have not yet reviewed or agreed to anything. Nothing here has been audited, reviewed, endorsed, or co-sponsored by Zellic or Circle. 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.
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