Canonical NAVCoin Transaction

This is the visual primer. The longer prose version has been moved to research notes.

PFTL official ledger path replacing the retired Ethereum-first demo path.

Slide 01

PFTL decides what exists.

The old demo proved market mechanics. The canonical design moves truth back to PostFiat L1, then lets venues trade verified claims.

The retired path treated the Ethereum token too much like the source of truth.
The correct path starts with PFTL proof state and native supply.
Ethereum receives a wrapped claim only after PFTL finality.

Rule: source chain first, venue second.

Slide instructions

Image: show a muted retired Ethereum-first path in the background and a bright PFTL-authorized path in the foreground. Animation: slow rightward push, scan beam, bullets reveal as the corrected path becomes primary.

End-to-end NAVCoin path from reserves to PFTL, wrapping, venue trading, privacy, and exit.

Slide 02

The whole path is one chain of custody.

A canonical transaction is not just a swap. It is a proof, an epoch, a supply change, a bridge receipt, a venue trade, and optional privacy.

Proof of reserves establishes verified net assets.
PFTL finalizes the epoch and controls supply.
Bridge and privacy steps are receipts over that source state.

Think: official ledger -> trading venues -> private settlement.

Slide instructions

Image: seven stations connected by clean rails: proof, PFTL, bridge, wrapped token, market venue, Orchard, exit. Animation: gentle breathing zoom, bullets reveal in transaction order.

Reserve sources feeding a cryptographic evidence packet.

Slide 03

First, prove the balance sheet.

NAVCoin starts with reserve evidence. The proof counts assets, cash, and liabilities, then binds the output to a timestamp and proof hash.

Assets and cash are reserve value.
Liabilities reduce that value.
The result is verified net assets, not a marketing number.

Formula: spot + cash - liabilities.

Slide instructions

Image: reserve legs fan into a proof engine and sealed packet. Animation: leftward pan and scan line, reinforcing inputs being checked before output.

Validators finalizing a NAV epoch around a ledger block.

Slide 04

PFTL finalizes a NAV epoch.

The proof is not useful until it becomes protocol state. Validators finalize an epoch that says which NAV number is current and fresh.

Validators verify the proof packet.
The chain records NAV per unit, timestamp, and freshness.
No fresh finalized epoch means no canonical mint.

Gate: fresh epoch required.

Slide instructions

Image: validator pillars closing a quorum ring around a finalized NAV block. Animation: pulse zoom to make the epoch feel like a confirmed checkpoint.

pfUSDC entering a policy gate and producing native NAVCoin on PFTL.

Slide 05

Native NAVCoin comes before wrapping.

A user brings counted value into PFTL. The NAV policy then mints or releases native NAVCoin under the current epoch.

The input is counted value, such as pfUSDC.
The policy gate checks the epoch and supply rules.
Native NAVCoin is the official unit.

Do not let a venue mint reality.

Slide instructions

Image: simple user-facing flow: stable value -> policy gate -> official ledger -> native units. Animation: breathing zoom, bullets reveal like a mint checklist.

PFTL bridge receipt minting wrapped NAVCoin on Ethereum.

Slide 06

Wrapping is a receipt, not a second coin.

To trade on Ethereum, PFTL debits or locks native NAVCoin, finalizes a receipt, and the Ethereum bridge mints the matching wrapped amount.

Debit or lock on PFTL.
Finalize a bridge packet with amount, asset, recipient, nonce, and destination.
Mint wrapped NAVCoin only from the verified packet.

Gate: no verified packet, no wrapped token.

Slide instructions

Image: two chain islands with a guarded receipt packet and replay seals. Animation: rightward push, making the receipt feel like it crosses from source to venue.

Verifier accepting an exact finalized packet and rejecting altered packets.

Slide 07

The bridge verifies finality.

The messenger is not trusted. Ethereum needs proof that PFTL actually finalized this exact receipt.

Source chain, destination chain, asset id, amount, recipient, nonce, and expiry are bound.
Changed packets fail.
Used nonces cannot mint twice.

Replay protection is part of the asset.

Slide instructions

Image: verifier gate with green accepted packet and red rejected branch. Animation: leftward pan and scan line to suggest proof checking.

Wrapped NAVCoin tethered back to official PFTL ledger state.

Slide 08

The wrapped token is a claim ticket.

The Ethereum token can be familiar to wallets and markets, but it is only valid because it traces back to a PFTL receipt.

It is convenient for Ethereum users.
It is not the official supply ledger.
Its redemption path points back to PFTL.

Analogy: resale ticket, not ticket office.

Slide instructions

Image: wrapped token in a transparent shell tethered to official PFTL ledger state. Animation: rightward push, emphasizing the tether to source truth.

Market pool with separate canonical NAV and market price gauges.

Slide 09

Uniswap is a venue, not the oracle.

The pool gives public liquidity and market price. The canonical NAV per unit still comes from PFTL.

Market price can differ from NAV.
The interface should show both numbers.
The pool cannot mint canonical supply by itself.

Show NAV/unit beside market price.

Slide instructions

Image: generic AMM pool with two separate gauges. Animation: gate pulse, because the key idea is separation between venue math and canonical proof math.

Public NAVCoin entering an Orchard shielded note commitment tree.

Slide 10

Shielding turns a public balance into a private note.

Orchard is the shielded pool. Instead of a public account balance, the wallet owns private notes and later spends them with proofs.

Public deposit creates a note commitment.
The owner stays wallet-side.
Nullifiers prevent double spend without revealing the note.

Orchard = notes + commitments + nullifiers.

Slide instructions

Image: public side passing through a privacy gate into a commitment tree. Animation: private drift and scan, suggesting a veil rather than a public ledger entry.

Zero-knowledge circuit consuming a pfUSDC note and emitting a NAVCoin note.

Slide 11

The private swap happens inside Orchard.

The wallet proves that it consumed the right input note and created the right output note without exposing the note details publicly.

Input: private pfUSDC note.
Circuit enforces conservation and allowed exchange.
Output: private NAVCoin note.

Validators see proof validity, not wallet path.

Slide instructions

Image: sealed notes entering and leaving a zero-knowledge circuit with a proof check below. Animation: private drift, making the note path feel hidden behind the proof.

Private Orchard note producing a public exit artifact without revealing note opening.

Slide 12

Private egress reveals only what the exit needs.

To return to a public bridge-out flow, the wallet proves it can open a valid note while disclosing only the public exit fields.

The note opening stays private.
The exit artifact is public and verifiable.
Bridge-out and redemption can proceed from that public artifact.

Privacy ends only at the chosen public exit.

Slide instructions

Image: hidden note behind veil, proof gate, public receipt and bridge-out path. Animation: private drift with reveal bullets, distinguishing hidden ownership from visible exit fields.

Safety gate dashboard for freshness, arithmetic, supply, replay, privacy proof, and market display.

Slide 13

Every dangerous shortcut gets a gate.

The system should fail closed when proof, supply, bridge, or privacy rules do not match.

Stale reserve proofs cannot power fresh minting.
Bridge packets cannot be replayed or rewritten.
Privacy proofs must verify before state changes.

Good UX says which gate failed.

Slide instructions

Image: six safety gates in a control-room grid with one closed stale gate. Animation: pulsing gate zoom and staged bullet reveal.

Complete user path from USDC bridge-in through private a651 swap and atomic handoff to Uniswap-side a651.

Slide 14

The user path ends at Uniswap-side a651.

The intended flow is explicit: bridge USDC into PFTL, privately swap into a651, then atomically hand off public a651 into the Uniswap-side representation.

USDC becomes pfUSDC on PFTL.
The Orchard swap privately turns pfUSDC into a651.
The public a651 exit feeds an atomic handoff to the Uniswap-side token.

User version: USDC -> PFTL -> private a651 -> atomic handoff -> Uniswap-side a651.

Slide instructions

Image: four-lane user path showing reserve proof, PFTL public state, Orchard privacy, and Ethereum/Uniswap venue. Animation: lane reveal in user-action order.

Atomic handoff from public PFTL a651 to Uniswap-side wrapped a651 using a matching lock, receipt, secret, and timeout refund.

Slide 15

The a651 handoff is atomic, not inventory-based.

The PFTL side locks public a651 under a swap id. The Ethereum side releases the Uniswap-side claim only after the matching finalized receipt is verified.

The PFTL lock binds asset, amount, recipient, and swap id.
Ethereum verifies the PFTL receipt before releasing wrapped a651.
If the handoff does not complete, the timeout path refunds instead of relying on inventory.

Atomic means both sides settle from the same proof, or the lock refunds.

Slide instructions

Image: PFTL hashlock escrow, finalized receipt, Ethereum verifier, wrapped a651 release, and timeout refund path. Animation: proof path lights first, then refund path remains as the fail-safe.