This is the beginner-friendly visual primer for the full route: USDC into PFTL, private a651 swap, atomic handoff, and Uniswap-side a651. The longer prose version has been moved to research notes.
Canonical NAVCoin Transaction
01 / 27

Slide 01
How do I turn USDC into a651 I can trade on Uniswap?
- a651 is the asset you want; the Uniswap pool is the public a651/USDC trading pair.
- PFTL keeps the official a651 record; pfUSDC is USDC recorded on PFTL; Orchard is the private swap area.
- Wrapped a651 is the Ethereum-side claim; atomic handoff means lock-and-release, or refund.

Slide 02
NAV is the accounting value behind a651.
- NAV means net asset value: reserve assets plus cash, minus liabilities.
- NAV/unit means that value divided by valid units.
- A NAVCoin follows those rules; a651 is the NAVCoin asset in this flow.

Slide 03
Proof of reserves checks what backs the coin.
- Proof of reserves is the evidence packet behind the NAV number.
- It counts assets and cash, subtracts liabilities, and records time plus an evidence fingerprint.
- It makes the process checkable; it does not make a dishonest data source honest.

Slide 04
PFTL decides what a651 officially exists.
- PFTL means Post Fiat L1, the base blockchain that records official a651 state.
- Uniswap is where people trade; PFTL is where the official a651 record is kept.
- A receipt is a public record of a PFTL action, and Ethereum-side a651 must trace back to one.

Slide 05
A NAV epoch is one accepted NAV snapshot.
- A NAV epoch is one finalized snapshot of NAV at a specific time.
- Validators—the chain’s checkers—accept the proof only if the math and freshness pass.
- No fresh epoch means no official a651 output.

Slide 06
Some steps are public; the middle swap is private.
- Public means anyone can see the ledger event.
- Private means the chain checks a proof while wallet details stay hidden.
- Mint is PFTL, purple is Orchard, cyan is Ethereum/Uniswap, amber is locks, red is reject or refund.

Slide 07
Step 1: you start with USDC.
- Your starting asset is normal USDC in a wallet or exchange route.
- At this moment, nothing private has happened.
- Next, you create a PFTL-recorded USDC balance.

Slide 08
Step 2: USDC becomes pfUSDC on PFTL.
- Bridge-in means a checked move from your starting USDC into a matching PFTL record.
- pfUSDC means that PFTL record of USDC.
- Public: asset, amount, recipient, and one-use id. Private: none yet.

Slide 09
Step 3: put pfUSDC behind the privacy boundary.
- Orchard is the private transaction area inside PFTL.
- A private note is a sealed wallet record; the chain only sees a public fingerprint called a commitment.
- Public: deposit and commitment. Private: owner, opening, and later route.

Slide 10
A nullifier lets privacy and accounting work together.
- A nullifier is a public spent marker created when a private note is used.
- It lets validators reject the same note twice without learning which note it was.
- Public: nullifier. Private: note opening and owner.

Slide 11
Step 4: Orchard swaps pfUSDC into private a651.
- Inside Orchard, your wallet spends a shielded pfUSDC note and creates a private a651 note.
- Validators check proof validity and the one-use nullifier, not your wallet path.
- Public: proof and nullifier. Private: input note, output note, route.

Slide 12
The chain checks the rule, not your private route.
- The proof says: a real note was spent once, the exchange is allowed under the current NAV epoch, and values balance.
- Validators accept the proof without reading the sealed notes.
- If any check fails, nothing changes.

Slide 13
After the swap, a651 is still private.
- After the swap, your wallet owns a private a651 note.
- Uniswap cannot trade that sealed note directly.
- To reach Uniswap, you must exit to public PFTL a651.

Slide 14
Step 5: private egress creates public PFTL a651.
- Private egress means leaving Orchard while revealing only the fields needed for public settlement.
- Your wallet proves the private a651 note is valid and unspent.
- Public: asset, amount, destination, receipt id. Private: old note details.

Slide 15
Public PFTL a651 is what gets locked.
- The public PFTL balance is the official a651 that can be locked for handoff.
- This public step is intentional: the Ethereum release needs a visible source record.
- Public: balance, exit receipt, and later lock.

Slide 16
Step 6: lock on PFTL, release on Ethereum, or refund.
- Atomic handoff means lock on PFTL, verify on Ethereum, then release matching Ethereum-side a651.
- If the verified release does not happen before timeout, the PFTL lock refunds.
- The target design does not rely on a middle party paying from inventory.

Slide 17
The PFTL lock says exactly what can be released.
- The lock records the exact deal: asset, amount, recipient, destination, deadline, and swap id.
- The swap id is the shared label that ties both sides to the same handoff.
- Changed fields, expired locks, or reused ids must fail.

Slide 18
Ethereum should verify the PFTL lock receipt.
- A relayer is just a messenger; it may carry the receipt but should not be trusted.
- Finality means PFTL has settled this exact lock as chain state.
- Ethereum verifies finality and fields before wrapped a651 can be released.

Slide 19
Wrapped a651 is useful, but it is not the official ledger.
- A wrapped token is an Ethereum token that represents a PFTL-locked claim.
- Wrapped a651 can move in Ethereum wallets and Uniswap, but it is not the official supply record.
- Public: mint/release event on Ethereum. Source of truth: PFTL.

Slide 20
Atomic means both sides settle, or the lock refunds.
- Success: lock → verified receipt → wrapped a651 released → lock consumed.
- Failure: timeout → refund public PFTL a651.
- A used receipt or expired lock must be rejected.

Slide 21
Step 7: trade wrapped a651 in the a651/USDC pool.
- A Uniswap pool is a public smart-contract market with two reserves.
- The a651/USDC pool lets users swap between wrapped a651 and USDC.
- Pool price is market price; PFTL NAV is the accounting value.

Slide 22
The complete path: USDC to Uniswap-side a651.
- USDC → PFTL/pfUSDC → shielded pfUSDC note → private Orchard swap → private a651 note.
- Then: private egress → public PFTL a651 → atomic lock/handoff → Ethereum-side wrapped a651.
- Finally: trade in the Uniswap a651/USDC pool.

Slide 23
The edges are public; the middle route is private.
- Public edges: bridge-in, egress, PFTL lock, Ethereum release, and Uniswap trade.
- Private middle: shielded notes and the Orchard swap route.
- The chain still checks proofs and nullifiers, so privacy does not remove accounting.

Slide 24
Do not call it trustless unless the contract verifies the proof.
- Trustless means contracts verify proof instead of trusting a messenger or committee.
- Final target: direct PFTL verification or a compact proof; staged versions may use committee signatures or challenge windows.
- Do not call a staged bridge production-trustless without deployment and verification evidence.

Slide 25
Every dangerous shortcut gets a gate.
- Fresh proof, supply rules, finality, one-use ids, nullifiers, and egress proofs all must pass.
- Good UX should explain which gate failed.
- Fail closed: no proof, no mint; reused id, no release; bad nullifier, no spend.

Slide 26
One route, one official record, one trading pool.
- You turn USDC into pfUSDC on PFTL, privately swap it into a651, then egress to public PFTL a651.
- PFTL keeps the official record; Ethereum-side wrapped a651 exists only after a verified lock/handoff.
- Uniswap is where wrapped a651 trades against USDC; it is not where official supply is decided.

Slide 27
This explains the design path; production claims need evidence.
- This packet explains the official design path; it does not prove the final bridge is live.
- Production evidence should include deployed contract addresses, verifier method, pool address, proof freshness source, and replay/nullifier checks.
- If any step is manual or committee-signed, label it staged.