AIR
Proof Lab
StartEcosystem
Explore (579)Live Systems (52)Pricing
Log InGet API Key✓ Verify It Yourself
Concept · Chain Portability

Chain portability is what tokenization was always missing.

Related · tier-1 reading. For what a portable artifact actually is, see Portable Artifact.

Most tokenization platforms anchor an asset to one chain. The asset and the chain become inseparable — change chains and you re-issue, re-KYC, re-document. Chain portability inverts this: the canonical identity is portable, the asset is canonical, and the chain becomes a cost optimization, not a lock-in.

Definition

Chain portability is the property that a piece of H33-74 evidence — a 74-byte post-quantum canonical identity — can be anchored to any blockchain that can store its 32-byte commitment, and re-verified identically against each, without re-issuance, bridging, or re-KYC. The evidence is chain-agnostic: it is produced once by H33-74 and merely published to a chain, so the chain becomes an interchangeable timestamp surface rather than the owner of the identity.

Why this exists. Chain-bound tokenization forces a multi-year institutional position to inherit the long-term fate of a single chain. Chain portability exists to decouple the durability of the evidence from the durability of any one chain, so a chain losing relevance in 2032 never moves the asset — only the publishing surface changes.

Boundary. H33-74 produces and anchors the evidence; it does not render the verdict — that is Verification. The chain provides an anchor and a timestamp only; it does not produce the evidence and does not decide whether it is valid. H33-74 does not depend on any chain: the same bytes survive migration across Bitcoin, Ethereum, Solana, Avalanche, Polygon, Optimism, Arbitrum, and Base, all of which are reference environments the evidence anchors to.

The problem with chain-bound tokenization

When a tokenization platform writes ownership state to a specific chain, the chain becomes load-bearing. The asset's identity, its compliance state, its KYC bundle, and its transfer history all live in that chain's storage. Moving to a different chain — for cost, throughput, or regulatory reasons — means re-issuing the token, re-running KYC, rebuilding the compliance trail, and accepting that the old chain's history fragments from the new chain's history.

This is why "multi-chain tokenization" almost always means wrapped tokens with bridges. The asset's identity gets fractured across chains; each chain has its own truth; bridges adjudicate between them. The result: more attack surface, more counterparty risk, and a worse story for institutional buyers who want a single source of truth.

What changes with a portable identity

If the canonical identity of an asset is a 32-byte commitment — a single content-addressable hash that any chain can store — then anchoring to a chain is no longer the act of creating the identity. It's the act of publishing an identity that already exists.

That changes three things at once:

  • Mint once, anchor anywhere. The 32-byte commitment can be written to Bitcoin via Taproot (BIP-341), to Solana via the memo program, to Ethereum via calldata or indexed event topics, to Polygon zkEVM as a STARK-backed privacy proof, to Zcash as a unique nullifier. The bytes are the same. The chain is the publishing surface.
  • No bridge, no wrapping. Bridges exist because the asset's identity is chain-bound. If the identity is portable by construction, you don't need a bridge — you just anchor the same bytes on a new chain. The asset isn't moving; the publishing record is expanding.
  • Chain choice becomes a cost decision. Want Bitcoin permanence? Anchor there. Want Solana throughput? Anchor there. Want Polygon zkEVM privacy? Anchor there. The identity is operationally invariant.

The mechanic in one line

commit = SHA3-256( asset_content ∥ authority ∥ timestamp ∥ policy_state )

Four inputs, concatenated, hashed. The output is a 32-byte commitment that uniquely identifies this asset under this authority at this moment under this policy. Three independent post-quantum signature families (ML-DSA-65 lattice · FALCON-512 NTRU · SPHINCS+ hash-based) sign over the commit. That's the 74-byte canonical identity. The 32 bytes go on whatever chain you want — including multiple chains. The 42 bytes of proof bundle live off-chain and are verifiable forever.

For the full demonstration, see /demo/tokenization-identity/ — real Solana mainnet anchor, same 32 bytes projected across every chain.

Why this matters institutionally

Chain portability isn't a developer convenience. It's a strategic primitive. An institutional buyer of tokenized assets cannot commit a multi-year position to a chain whose long-term roadmap is uncertain. They need to know that if Chain X loses relevance in 2032, the asset doesn't move with it — only the publishing surface does.

This is also why we put institutional continuity at the center of the architecture. The verification doesn't depend on H33 existing in 2050; the publishing chain doesn't have to either, as long as a single chain in the receipt corpus survives. Resilience is constructed by redundancy of anchoring, not by trust in any single chain.

When to use chain portability — and when not

  • Use it when the position is long-lived, the chain roadmap is uncertain, or an institutional buyer needs a single source of truth that does not fracture across wrapped tokens and bridges.
  • Use it when you may need to add or change publishing surfaces later (cost, throughput, privacy, or regulatory reasons) without touching the identity.
  • You do not need it when the record is ephemeral, single-chain by mandate, and never audited past the life of that chain — a plain single-chain write is simpler. Portability is about durability of evidence, not throughput of transactions.
  • It is not a bridge, an oracle, or a verdict. If you need cross-chain asset movement, that is a bridge (a different, higher-risk mechanism). If you need a trust decision, that is Verification. Chain portability only makes the same evidence re-anchorable and re-verifiable.

Frequently asked questions

Does H33 own or run the blockchains it anchors to?

No. Bitcoin, Ethereum, Solana, Avalanche, Polygon, Optimism, Arbitrum, and Base are external reference environments. H33-74 evidence anchors to them; H33 does not own, operate, or control any chain, and the chain does not produce the evidence.

Does the evidence depend on any one chain to stay valid?

No. The 32-byte commitment is content-addressable math, not a chain artifact. It is re-verifiable offline against the published schema and hash, trusting no chain. A chain provides only an anchor and timestamp; if a chain disappears, the same bytes remain verifiable and can be re-anchored elsewhere.

Is anchoring the same as verification?

No. Anchoring is publishing a commitment to a chain. Rendering the verdict — is this evidence valid, under what authority — is Verification. Governing what an agent was permitted to do is Agent-008. Chain portability is strictly about the evidence primitive produced by H33-74 staying portable.

Which chain should I anchor to?

Whichever fits the requirement: Bitcoin (Taproot) for permanence, Solana for throughput, an EVM L2 for interop, a zk path for privacy. Because the identity is chain-agnostic you can anchor to several for redundancy — the right question becomes "how redundant is your anchoring," not "which single chain."

Owner & boundaries

This concept is an expression of H33-74, which produces and anchors the portable 74-byte post-quantum evidence primitive. External chains are reference environments the evidence anchors to — never owned, never the producer. The verdict on that evidence is rendered by Verification; authority over agent actions is governed by Agent-008. Cryptographic primitives (SHA3-256, ML-DSA, SLH-DSA) and chain mechanisms (Taproot, OP_RETURN) are external standards H33-74 uses, not inventions it owns.

Discovery
Where to go next