Trustless Wrapped Stablecoins on PFTL

By: Post Fiat
Scope: Primer and technical specification for bringing wrapped USDC and other external stablecoins onto PFTL, covering the protocol that exists today and the staged roadmap to full trustlessness

This document follows one terminology rule throughout:

“Trustless” is reserved for a tier where the destination chain verifies finalized source-chain facts through a permissionless verifier, directly or through a sound succinct proof.

Threshold-signed systems are trust-based. Observer and optimistic systems are trust-minimized within their stated assumptions. Each deployment should claim exactly its enforced tier and nothing above it.

1. Executive summary

A wrapped stablecoin system must answer two questions:

1. What evidence permits PFTL to issue wrapped atoms after a source-chain deposit?
2. What evidence permits the source-chain vault to release underlying atoms after a PFTL burn?

PFTL answers the first question today with a consensus-enforced observer ceremony. A user deposits USDC into ERC20BridgeVault, choosing a PFTL recipient. Evidence for that deposit is proposed on PFTL, checked against exact observations from registered observers, finalized under a fail-closed quorum rule, and claimed by the named recipient.

At Tier 1, PFTL validators do not independently prove source-chain inclusion or finality. They validate that the submitted evidence is internally consistent and that enough registered observers reported matching source-chain facts. The system is therefore independently observed, not trustless.

The exit path is also interim: a PFTL burn produces a withdrawal packet that passes through source-chain challenge windows and a threshold-based verifier before the underlying is released. PFTL then records settlement using a withdrawal-observation quorum.

Control minimization is the design trajectory, not a completed Tier-1 property. Today’s authority surface includes:

• registered observers and the profile’s min_attestations;
• authorized role accounts, including issuer, reserve_operator, and redemption_account;
• profile and activation governance;
• a source-chain vault owner-held pause;
• a designated source-chain challenge authority; and
• an interim threshold verifier for exits.

The tier ladder retires these dependencies in stages: receipt proofs remove observers from entry safety, finality proofs remove governed checkpoints from entry safety, and succinct PFTL-finality proofs replace the threshold exit verifier. The target is a round trip whose cross-chain facts are verified permissionlessly in both directions.

1.1 Consensus validity rules versus application contracts

All destination-chain validators execute application contracts, so the important distinction is not simply “consensus versus contract” or where code is physically located. The meaningful differences are:

1. Evidence requirements. A signature-checking bridge accepts facts authorized by its committee or issuer. PFTL’s bridge transaction kinds require evidence under a state-committed verification profile. At Tier 1 that evidence is an observer quorum; at higher tiers it becomes receipt inclusion and source-chain finality proofs.
2. Rule mutability and capture resistance. PFTL bridge validity rules and profiles change through visible L1 governance and are committed to chain state. An application bridge may instead be governed through the application’s own admin keys or committee.
3. Block validity. A PFTL block containing a bridge operation that fails the active validity rules is invalid to PFTL validators. This does not make the source-chain assertion true by itself: at Tier 1, external truth still depends on the observer-honesty and source-chain-reorg assumptions described below.

The architecture therefore creates a stable verification locus while allowing the evidence standard to ratchet upward.

2. Primer: assets, evidence, and conservation

A wrapped stablecoin on PFTL is a native PFTL asset backed by an external stablecoin held in a source-chain vault. For USDC:

• asset code: PFUSDC;
• precision: 6 decimals;
• VAULT_BRIDGE_UNIT = 1,000,000 atoms per whole token; and
• one pfUSDC atom represents one micro-USDC.

The bridge has two separate concerns:

• authorization: whether evidence satisfies the current verification tier; and
• accounting: whether deposits, issued atoms, burns, releases, and settlements conserve value through every lifecycle state.

2.1 Full lifecycle accounting model

A two-term equation such as “vault balance equals issued supply” is correct only when no deposit or redemption is in flight. The full model uses four state quantities:

• V: USDC atoms held by the source-chain vault;
• S: issued pfUSDC atoms on PFTL;
• D: atoms deposited into the vault but not yet credited on PFTL;
• B: atoms burned on PFTL whose redemption has not yet been settled on PFTL; and
• R: the subset of B already released by the source-chain vault but not yet settled on PFTL.

The conservation identity is:

V = S + D + B - R

R is subtracted because a released-but-unsettled redemption remains open in PFTL’s lifecycle records but is no longer held by the vault.

For an exact amount x, the state transitions are:

This explicitly covers the released-but-unsettled window. Immediately after source-chain release, vault balance and issued supply may again be equal, but the redemption remains operationally open until vault_bridge_redeem_settle removes both B and R.

2.2 Comparison by evidence and authority

A Tier-1 evidence record can be syntactically perfect and still be false. The observer quorum is what rejects that well-formed lie—unless enough observers collude or share a common failure. Tier 2 removes that observer-collusion path for receipt inclusion, while Tier 3 verifies the header’s finality rather than trusting a governed checkpoint.

3. Technical specification: what exists today

The implementation is in postfiatorg/postfiatl1v2.

Normative and implementation references include:

• docs/vault-bridge-deposit-evidence-spec.md;
• crates/execution/src/nav_vault_asset_execution.rs;
• crates/types/src/core_chain.rs; and
• crates/ethereum-contracts/src/.

3.1 Source-chain vault

ERC20BridgeVault holds the external stablecoin on source chain id 42161, Arbitrum One, for native USDC. Its deposit interface is permissionless:

function deposit(uint256 amount, string calldata pftl_recipient, bytes32 nonce)
    external nonReentrant returns (bytes32 deposit_id)

The vault derives:

deposit_id = keccak256(abi.encode(
    "postfiat.erc20_bridge.deposit.v1",
    block.chainid, vault, token, depositor,
    amount, keccak256(pftl_recipient), nonce))

This binds the source chain, vault, token, depositor, amount, recipient hash, and nonce. Evidence naming another recipient fails recomputation.

The current administrative surface includes an owner-held pause and a designated challenge authority. These remain Tier-1 trust and liveness dependencies. The target posture retires administrative control in favor of an immutable, unpausable vault and permissionless bonded challenges.

3.2 Deposit evidence

A deposit becomes a twelve-field VaultBridgeDepositEvidence record containing:

• source chain id;
• vault and token addresses;
• depositor;
• PFTL recipient and recipient hash;
• amount in atoms;
• nonce;
• deposit id;
• block hash;
• transaction hash; and
• log index.

deposit_id and pftl_recipient_hash are re-derived during validation. They are not trusted as free-standing assertions.

The node CLI operation vault-bridge-deposit-relay-rpc-bundle builds evidence from a live source-chain receipt. The relay transports evidence but does not make it valid.

3.3 Four-operation credit ceremony

1. vault_bridge_deposit_propose

Admission requires:

• a registered asset using a vault_bridge:<source_domain> proof profile;
• a matching source policy and policy hash;
• an unexpired proposal;
• an evidence root that recomputes from the submitted fields; and
• no existing (asset_id, evidence_root) pair.

Duplicate evidence roots are therefore rejected structurally.

2. vault_bridge_deposit_attest

Each attestor must be a registered, identity-bearing observer. Its observation must match the evidence exactly:

• the transaction exists;
• receipt status is success;
• source chain id matches;
• vault matches;
• token matches;
• depositor matches;
• amount matches;
• deposit id matches;
• block hash matches;
• transaction hash matches;
• log index matches; and
• confirmation depth satisfies bridge_observer_min_confirmations.

These are discrete EVM facts, so tolerance_bp does not apply. The rule is exact equality.

Distinct observer identities do not by themselves prove operational independence. Shared RPCs, infrastructure, or control can create common-mode failures even when registrations are distinct.

3. vault_bridge_deposit_finalize

Finalization requires:

pass_count >= min_attestations
fail_count == 0

A single recorded failure blocks finalization. The operation also enforces challenge-window and snapshot-age rules.

4. vault_bridge_deposit_claim

The claimant and amount must match the evidence. Issued supply uses checked addition and cannot exceed max_supply.

A vault_bridge_deposit_challenge can contest a proposal during its window and is bonded by min_challenge_bond.

The development-network profile uses a quorum of 3 observers and a minimum confirmation depth of 6. These are profile parameters, not universal security constants. Six confirmations do not eliminate the possibility of a deeper source-chain reorganization.

Activation is governed through ratify-bridge-verification-activation-height. Observer registration, quorum sizes, source bindings, and confirmation requirements are visible in state rather than controlled through a relayer toggle.

3.4 Redemption lifecycle

Redemption has three accounting stages and five source-chain verifier/vault operations.

Stage 1: burn on PFTL

The user submits:

vault_bridge_burn_to_redeem

The operation burns wrapped atoms, names a source-chain recipient in the form:

evm-erc20:42161:<address>

and produces a redemption id.

Accounting transition:

S -= x
B += x

Stage 2: verify and release on the source chain

A withdrawal packet is digest-bound to the redemption and proceeds through:

submitProof
→ finalizeProof
→ submitWithdrawal
→ finalizeWithdrawal
→ claimWithdrawal

The packet clears a challenge window at the verifier and another at the vault before release.

When the vault releases x atoms:

V -= x
R += x

At this point the user has received the source asset, but PFTL has not yet closed the redemption. B remains outstanding and R records that the outstanding redemption has already been released.

The source-chain verifier currently uses an interim threshold posture. Compromise of the required threshold can affect exit safety; unavailability of the threshold can halt exits.

Stage 3: settle on PFTL

vault_bridge_redeem_settle requires a quorum of withdrawal observations. Each observation must match the withdrawal packet exactly and carry a valid observer signature.

Settlement applies:

B -= x
R -= x

The redemption is then closed on both sides of the accounting model.

3.5 Reserve and NAV integration

Four additional consensus kinds consume wrapped stablecoin receipts as verified reserve capacity for NAV assets:

• vault_bridge_receipt_submit;
• vault_bridge_receipt_count;
• vault_bridge_mint_from_receipts; and
• vault_bridge_nav_subscription_allocate.

The associated profile fields include valuation_unit, valuation_policy_hash, and tolerance_bp. valuation_policy_hash binds the selected valuation policy, while tolerance_bp supplies valuation tolerance for NAV processing. It is unused when validating discrete EVM deposit facts, which require exact equality.

vault_bridge_bucket_impair marks impaired backing buckets.

3.6 Guarantees and their conditions

Enforced unconditionally by the active PFTL rules

The following properties hold for blocks accepted under the active rules and profile:

• submitted recipient hashes and deposit ids must recompute;
• duplicate evidence roots are rejected;
• observation fields must match evidence exactly;
• finalization requires pass_count >= min_attestations and fail_count == 0;
• claims must use the evidence recipient and amount;
• checked arithmetic and max_supply constrain issuance; and
• rule and profile changes are visible through PFTL state and governance.

These properties establish internal consistency. They do not independently prove that a Tier-1 source-chain report is true.

Conditional Tier-1 safety guarantees

Tier-1 entry safety additionally requires:

• fewer than min_attestations registered observers collude to report a false event;
• observers do not suffer a quorum-wide common-mode data failure;
• the accepted source-chain history does not undergo a reorganization deeper than the profile’s confirmation assumption; and
• profile or activation governance is not captured and used to weaken or redirect the verification policy.

Tier-1 exit safety additionally requires:

• the threshold exit verifier is not compromised;
• the source-chain vault and challenge authority operate within their disclosed powers;
• withdrawal observers do not provide a false settlement quorum; and
• source-chain release facts remain canonical.

The statement “faults degrade liveness, never safety” is therefore valid only under these honesty, governance, verifier, and source-chain-history assumptions. Outside them, observer-quorum collusion, profile-governance capture, deep source-chain reorganizations, checkpoint-governance capture at Tier 2, and threshold-verifier compromise can violate safety.

3.7 Failure and recovery behavior

Permissionless relay reduces transport censorship but does not guarantee that observers, governance, the vault, or the threshold verifier remain available.

3.8 Tier-by-tier threat model

The bridge is “trustless” only for the directions whose finalized cross-chain facts are permissionlessly verified. Tier 3 earns that term for entry. Tier 4 earns it for the round trip.

4. Operational guide

4.1 Wrap sequence

 user              vault (source chain)         relay              PFTL validators/observers
  |                       |                       |                            |
  |-- approve ----------->|                       |                            |
  |-- deposit ----------->|                       |                            |
  |                       |-- Deposit event ----->|                            |
  |                       |                       |-- evidence proposal ------>|
  |                       |<~~~~ observers read source-chain receipt ~~~~~~~~~|
  |                       |                       |-- attestations ----------->|
  |                       |                       |-- finalize --------------->|
  |                       |                       |-- claim ------------------>|
  |<========== PFUSDC credited to deposit-bound recipient ====================|

4.2 Wrap procedure: USDC to pfUSDC

1. The user holds native USDC on source chain id 42161.
2. The user calls approve.
3. The user calls deposit(amount, pftl_recipient, nonce).
4. The vault transfers the tokens and returns a deposit_id binding the chosen recipient.
5. Any party runs vault-bridge-deposit-relay-rpc-bundle against a source-chain RPC.
6. PFTL processes propose, observer attest operations, finalize, and claim.
7. The exact atom amount is credited. A deposit of 250 USDC corresponds to 250,000,000 pfUSDC atoms.
8. The integrator checks the full conservation equation, including deposits still awaiting claim.

4.3 Unwrap sequence

 user                    PFTL               source verifier             vault              PFTL
  |                        |                       |                      |                   |
  |-- burn_to_redeem ----->|                       |                      |                   |
  |                        |-- withdrawal packet ->|                      |                   |
  |                        |                       |-- submitProof ------>|                   |
  |                        |                       |-- finalizeProof ---->|                   |
  |                        |                       |-- submitWithdrawal ->|                   |
  |                        |                       |-- finalizeWithdrawal>|                   |
  |-- claimWithdrawal -------------------------------------------------->|                   |
  |<========================== source USDC released =====================|                   |
  |                        |<~~~~ withdrawal observers read release fact ~~~~~~~~~~~~~~~~~~~~|
  |                        |------------------------------------------------ redeem_settle -->|
  |<============================= redemption closed ========================================|

4.4 Unwrap procedure: pfUSDC to USDC

1. The user submits vault_bridge_burn_to_redeem and names their source-chain address.
2. The burn reduces S and increases B.
3. The digest-bound packet advances through submitProof, finalizeProof, submitWithdrawal, finalizeWithdrawal, and claimWithdrawal.
4. Release reduces V and increases R; the redemption is now released but unsettled.
5. Withdrawal observers attest to the exact packet and release.
6. vault_bridge_redeem_settle reduces both B and R, closing the lifecycle.

4.5 Integrator requirements

• Read all profile parameters from chain state. Do not hardcode quorum size, confirmation depth, challenge windows, deadlines, source bindings, or verifier_kind.

• Treat relays as untrusted transport. Verify accepted PFTL operations rather than a relayer’s report.

• Track the full accounting identity:

  V = S + D + B - R
  

• Distinguish “burned but not released” from “released but not settled.” The latter has already left vault custody.

• Treat any unexplained conservation mismatch as a halt condition.

• Support self-relay where practical.

• Display the active verification tier in wallet and application UX.

• Describe Tier-1 credits as independently observed, not “proven” or “trustless.”

• Monitor governance changes to profiles, activation state, observer registration, source bindings, and verifier selection.

• Treat the current exit threshold as an explicit authorization dependency.

5. Roadmap: from observation to trustless verification

Each tier upgrades the evidence accepted by the bridge rules. Governance activation must precede any stronger public claim.

Tier 1 — Independently observed

The current development-network system uses:

• registered observers;
• exact fact matching;
• min_attestations;
• fail_count == 0;
• source-chain confirmation minimums;
• challenge windows;
• bonded deposit challenges; and
• state-committed profiles.

The development-network profile uses 3 observers for quorum and a minimum confirmation depth of 6.

Tier-1 safety depends on preventing a quorum from colluding or sharing a false source view. Distinct registrations, infrastructure, or RPC providers can reduce common-mode risk but do not cryptographically enforce independence.

Permitted claim: independently observed deposits.

Tier 2 — Receipt-proven

The entry rule upgrades to a Merkle-Patricia receipt-inclusion proof against a block’s receipts root. verifier_kind is the profile seam for moving from multi_fetch to sp1-groth16.

The header anchor uses the governed EthereumFinalizedCheckpointV1 machinery. A valid inclusion proof prevents an observer quorum from inventing a receipt, but governed checkpoint correctness remains a safety assumption.

Permitted claim: receipt-proven deposits.

Tier 3 — Finality-verified entry

A light-client or succinct-proof pipeline verifies source-chain finality, including Ethereum consensus and Arbitrum settlement into it, rather than accepting a governed checkpoint as authoritative.

Entry then satisfies this document’s definition of trustless verification: finalized source-chain facts are verified through a permissionless verifier.

Permitted claim: trustless entry.

Tier 4 — Proof-verified exit

The source-chain verifier replaces its threshold signature check with verification of succinct proofs of PFTL consensus finality.

PFTL uses post-quantum ML-DSA signatures, which are impractical to verify directly in the EVM. The design path proves PFTL finality through the SP1/Groth16 lane and verifies a constant-size proof on the source chain. PFTL’s Halo2 private-swap stack provides the existing succinct-proof competence referenced by this roadmap.

Until this tier is activated, the threshold signer set remains the exit trust boundary.

Permitted claim: trustless round trip.

Tier 5 — Canonical alignment

For USDC, the asset conforms to Circle’s Bridged USDC Standard and preserves the path for the bridged representation to be superseded by native USDC issuance on PFTL.

This tier changes canonical asset alignment rather than weakening the Tier-4 proof requirement.

Permitted claim: canonical-aligned USDC with a trustless bridge round trip, where Tier 4 remains enforced.

6. Control-minimization checklist

Entry and evidence

• deposit() is permissionless
• The depositor chooses the PFTL recipient
• The recipient hash is bound into deposit_id
• deposit_id and pftl_recipient_hash are re-derived during validation
• Duplicate (asset_id, evidence_root) pairs are rejected
• Tier-1 observations match evidence exactly
• Finalization requires pass_count >= min_attestations
• Finalization requires fail_count == 0
• Tier-2 claims are not used until receipt proofs are enforced
• Trustless-entry claims are not used until source finality is permissionlessly verified

Supply and redemption accounting

• Issuance uses checked arithmetic
• Issued supply cannot exceed max_supply
• Operators track V, S, D, B, and R
• The monitored identity is V = S + D + B - R
• Released-but-unsettled redemptions are recorded separately from unreleased burns
• vault_bridge_redeem_settle requires matching withdrawal observations
• Any unexplained accounting divergence is a halt condition

Authority and governance

• Registered observer identities and active quorum are visible
• Operational independence is assessed separately from observer identity
• issuer, reserve_operator, and redemption_account are enumerated
• Vault owner pause authority is disclosed
• Source-chain challenge authority is disclosed
• Vault upgradeability is disclosed
• Exit-verifier signers and threshold are disclosed
• Profile and activation governance thresholds are disclosed
• Governance changes are visible on-chain
• Administrative authorities have explicit retirement conditions on the tier ladder
• The threshold exit verifier is not described as trustless

Operations and public claims

• Relayers hold no verification authority
• Users can self-relay
• Integrators read profiles from state
• Confirmation depth is not described as absolute source-chain finality
• Tier 1 is labeled “independently observed”
• Tier 2 is labeled “receipt-proven”
• Tier 3 uses “trustless” only for entry
• “Trustless round trip” is used only after Tier 4 activation
• Bridged USDC Standard alignment is tracked separately from proof-verification status

7. Scope and limitations

This document describes the PFTL development-network protocol and its design-committed roadmap. Tier 1 is active under a governance-activated height; Tiers 2–5 are not the currently enforced evidence standard. Development-network parameters must be read from chain state.

This is a public research primer, not an audit or mainnet deployment announcement. Exact deployed contract addresses, activation heights, pinned source commit hashes, observer-set composition, observer compensation or slashing arrangements, bond-sizing rationale, governance thresholds, exit-verifier signers and threshold, and source-vault upgradeability are [TBD: maintainers]. No quantified economic claim about the cost of observer collusion follows from min_challenge_bond, min_attestations, or max_supply alone.

The current profile’s confirmation depth of 6 is an acceptance parameter, not a proof of Arbitrum or Ethereum finality. Tier 1 remains exposed to deeper source-chain reorganizations and observer common-mode failures. Tier 2 remains exposed to governed-checkpoint correctness. The exit remains threshold-authorized until Tier 4.

This document is not legal, regulatory, or investment advice.

Appendix A — Deposit evidence schema

VaultBridgeDepositEvidence is specified in docs/vault-bridge-deposit-evidence-spec.md.

Tier-1 observations require exact equality on:

source_chain_id
vault
token
depositor
amount_atoms
deposit_id
block_hash
tx_hash
log_index

They additionally require:

tx_exists
receipt_status == 1
confirmation_depth >= bridge_observer_min_confirmations

No tolerance band applies to these facts.

Deposit identifier

deposit_id = keccak256(abi.encode(
    "postfiat.erc20_bridge.deposit.v1",
    block.chainid,
    vault,
    token,
    depositor,
    amount,
    keccak256(pftl_recipient),
    nonce
))

Appendix B — Transaction kind reference

The twelve vault_bridge_* consensus kinds are defined in crates/types/src/core_chain.rs.

Credit ceremony

• vault_bridge_deposit_propose
• vault_bridge_deposit_attest
• vault_bridge_deposit_finalize
• vault_bridge_deposit_claim
• vault_bridge_deposit_challenge

Redemption

• vault_bridge_burn_to_redeem
• vault_bridge_redeem_settle

Reserve and NAV integration

• vault_bridge_receipt_submit
• vault_bridge_receipt_count
• vault_bridge_mint_from_receipts
• vault_bridge_nav_subscription_allocate

Impairment

• vault_bridge_bucket_impair

Appendix C — Parameter reference

Per-asset profiles use VaultBridgeBootstrapBundleOptions and are committed to PFTL state.

Chain constant:

VAULT_BRIDGE_UNIT = 1,000,000

Governance and registry operations include:

• ratify-bridge-verification-activation-height; and
• observer registration through the on-chain attestor registry.

Appendix D — Trust-model comparison matrix

Appendix E — Integrator quick reference

Read from chain state

• source_chain_id
• vault_address
• token_address
• verifier_kind
• min_attestations
• bridge_observer_min_confirmations
• challenge_window_blocks
• min_challenge_bond
• max_snapshot_age_blocks
• max_epoch_gap_blocks
• settle_deadline_blocks
• max_supply
• role accounts
• observer registry
• activation state

Verify the lifecycle

Deposit:   V += x, D += x
Claim:     S += x, D -= x
Burn:      S -= x, B += x
Release:   V -= x, R += x
Settlement B -= x, R -= x

At every lifecycle state:

V = S + D + B - R

Use precise public language

Operational alerts

Treat each of the following as an investigation or halt condition:

• unexplained conservation mismatch;
• unexpected profile or source-binding change;
• unexpected observer-registry change;
• quorum or confirmation-depth reduction;
• vault pause;
• stale or repeatedly expiring ceremonies;
• source-chain reorganization affecting accepted evidence;
• release without timely PFTL settlement;
• threshold exit-verifier unavailability; or
• public claims exceeding the active verifier_kind and tier.