First Tokenized Asset Transfer
with Replayable Authority.

01The transfer workflow

A tokenization platform — Ondo, Securitize, Kinexys, a transfer agent, a fund administrator — processes asset transfer requests every day. Each request requires an authorized approver to sign off. The platform records the approval. Three years later, a regulator asks: who approved this transfer, under what authority, against what policy, and can you reconstruct the answer from independently verifiable evidence?

Most platforms have a database row that says "Approver X approved at time Y." That's a record-keeping claim. H33 replaces that with reconstruction. Given the canonical event log and the moment of approval T, anyone can rebuild the authority state that justified the decision. Same chain, same yardstick, same forensic outputs as the V101 first proof — different use case.

02The reconstructed state_id

03The transfer approval authority

Forensic explanation

{
  "authority_id": "auth_e5f1d6f9-…_transfer_approval",
  "included": true,
  "reason": "Granted by princ_root_tokenize_e5f1d6f9-… to princ_approver_001;
             policy pol_transfer_approval_v1; chain to root verified."
}

The full reconstruction artifact: reconstruction.json.

04Why this matters for tokenization

Three years from now, a regulator asks "who approved this transfer?". With H33, the answer is reconstructable from the canonical event log alone — same approver principal, same authority grant, same policy basis, byte-identical state_id, every time. The platform does not have to trust its own database migration. The auditor does not have to trust the platform.

For tokenized assets specifically, this answers the four questions a regulator most cares about:

• Who authorized the transfer? The approver principal, named on the receipt.
• Under what authority? The authority_id, traceable to a signed grant in the canonical event log.
• Against what policy? The policy_basis, traceable to a signed policy_register event.
• Can you reconstruct this three years from now? Yes. Same events. Same T. Same state_id.

05Live anchor (pending operator action)

The upgrade path:

1. Auth1 mints a fresh EdDSA Bearer with sub = princ_approver_001, aud = substrate-receipts — standard 15-min canonical-token flow.
2. The Bearer is presented to POST https://api.h33.ai/api/v1/h33-auth/v101-bundle-issue with the tokenization tenant ID, requested_capability = approve_transfer, and a transfer-flavored decision_description (asset ID, holder, recipient).
3. H33SubstrateAnchorSink produces a 74-byte H33-74 receipt over the IssuedReceipt commitment — the same format and the same anchor chain (h33-substrate-v1) as V101's first bundle.

The receipt would carry authority_id = auth_e5f1d6f9-…_transfer_approval, policy_basis = pol_transfer_approval_v1, and a source_jti tying the receipt to the approver's specific Bearer. Anchored. Reconstructable three years later.

06Known limitations

1. Reconstruction-only, not live anchor. Authority is real, events are signed with production keys, reconstruction is byte-identical — but no live receipt issued yet. Live anchor earns its own promotion to "first-tokenized-transfer-anchored."
2. Structural tokenization tenant, not a real platform. Ondo / Securitize / Kinexys / a transfer agent has not yet integrated. When the first one does, this proof gets superseded by "first-real-tokenization-platform-transfer."
3. One transfer scenario, not a corpus. Single grant, single approver, single policy. Multi-approver flows, quorum approvals, limits-based escalation are not yet tested.
4. No transfer-instance receipt schema. Receipt format is the generic IssuedReceipt; tokenization platforms may want richer wrapping (asset ID, settlement reference). That belongs in a v2 spec.
5. AuthEvent.signature not verified at replay ingestion (Phase E lock).

07Evidence appendix

08Deployment commit SHAs

09Readiness determination

What this unlocks: conversations with Ondo, Securitize, Kinexys, transfer agents, fund administrators, and regulators about whether the canonical-auth chain handles their transfer-approval flow. The answer is the reconstruction artifact. Live anchor follows in one operator step.

What this does not unlock: a claim that any production tokenization platform has integrated; a claim that the chain handles multi-approver / quorum / corridor flows; a claim that transfer-instance schemas are finalized.