Open-source technical preview

The payment should carry its own terms.

T3 is a reference implementation for programmable transfer envelopes: value movements that carry issuer attribution, expiration behavior, dispute handling, and settlement context on a permissioned bank ledger.

It is not a production-audited product, a deposit claim, or a legal opinion. It is a worked argument in code: which controls should a bank-ledger payment primitive be able to express?

Review the Code Explain It to a Banker Inspect the Architecture
41
Diamond facets composed behind one proxy
1,545
Passing tests in the public release
Off
Banking feature gates ship disabled by default
Apache‑2.0
Open for review, critique, and issue filing
From blind transfer
sender recipient final
To programmable envelope
Envelope
issuer terms expiration dispute path settlement mode audit trail
finalize reverse expire hold dispute

The rail does not make policy disappear. It gives policy a place to live.

How to read the project

Three ideas before the feature list.

T3 is easiest to evaluate when the story moves from primitive, to accountability, to activation gates.

01

Transfers become envelopes.

The core primitive is not just sender, recipient, and amount. It is an escrowed instruction with lifecycle rules.

02

Liability stays attributable.

Issued value can remain linked to the responsible institution, so cross-bank movement does not collapse into an ambiguous pooled balance.

03

Activation is deliberately gated.

Banking capacity and settlement features are present for review, but disabled by default until counsel, controls, and operations are ready.

What not to over-read

This release does not claim FDIC insurance, regulator approval, production readiness, settlement-finality guarantees, or a complete compliance program.

Read the documented gates

Exception handling is the real test.

A payment primitive is only serious if it can describe what happens when the transfer is wrong, disputed, abandoned, or still waiting on fiat confirmation.

A modeled fraud-recovery flow

A corporate payment is sent to the wrong party. In the reference design, the transfer can sit inside a governed envelope window instead of becoming an immediate blind balance update.

  • 00:00 - Funds enter an envelope with issuer attribution and lifecycle terms.
  • Review - A policy or operator can route the envelope to hold, dispute, reverse, or finalize.
  • Record - The resulting state transition remains part of the ledger history.

Why It Matters

  • Reviewers: The rail can express intervention windows without hiding the policy decision off-ledger.
  • Bank Ops: Exception handling becomes a modeled state path, not only a ticket and a reconciliation file.
  • Developers: The lifecycle is inspectable in Solidity, tests, events, and storage layout.
  • Analog fallback: Cambio notes remain one application of the envelope idea, not the main story. Try the demo.
Explore the Scenario

Born from Adversity, Built for Accountability

Our founder lost $44,000 in minutes. No bank, no regulator, and no blockchain had a remedy—so we engineered one.

APR 2025

HalfLife Undo Button Invented

Designs a reversible transaction primitive that keeps instant settlement while offering an authorized recall window.

JUN 2025

Diamond Architecture Deployed

Implements 41-facet upgradeability so every control—rules engine, programmable fee reserves, SmartLock—stays modular and auditable.

TODAY

Published as open source

41 facets and 1,545 passing tests, running against a permissioned Hyperledger Besu consortium, published under Apache-2.0 with the open legal and compliance questions documented rather than omitted.

From a $44K loss to a safer financial system.

Read how the origin story informs T3’s mission, governance philosophy, and relentless focus on protecting consumers.

Explore Our Story

The feature list has a hierarchy.

The modules are easiest to understand as support for the envelope model, not as disconnected product claims.

Envelope Lifecycle

Transfers can carry expiration behavior, dispute handling, manual holds, and finalization paths.

Claim Attribution

Issued value can remain tied to the responsible institution so settlement accounting is reviewable.

Rules Engine

Scoped policy checks, allow/deny lists, and observation mode let reviewers separate plumbing from compliance program claims.

Diamond Architecture

Forty-one facets keep the implementation modular while preserving a single programmable fiat surface.

Ready for a deeper technical dive?

See the HalfLife demo, selector maps, and policy modules inside the T3Token Diamond.

View Technology Overview
Built for review

The open questions are part of the release.

41 facets Modular Diamond design for architectural review.
1,545 tests Coverage across envelope, policy, and Cambio flows.
Gates off Banking activation requires deliberate administrative action.
Banker View

Translate the architecture into operating questions.

Start here if you evaluate payment rails, risk controls, settlement accountability, or counsel gates.

Envelope

A transfer that carries its own terms: when it expires, what happens if nobody accepts it, who may dispute it, and which institution issued the money.

You already know this as: a payment instruction with conditions attached, except the conditions are enforced by the ledger rather than by an operations team reading them.
HalfLife window

A defined period after a transfer during which an authorised party can unwind it. After the window closes, it is final.

You already know this as: a wire recall, but one that completes inside the same system that sent the funds, instead of a phone tree and a correspondent's goodwill.
Observation mode

The transaction-screening engine scores every payment and blocks nothing, so you can see what it would have stopped before it stops anything.

You already know this as: running a new fraud model in parallel with the incumbent before you cut over. Nobody switches a control on blind.
Claim attribution

Every unit of money on the ledger records which member institution issued it, so liabilities can be tracked and substituted between institutions.

You already know this as: knowing which correspondent owes what. A pooled balance nobody can attribute is not something you can settle against.
Permissioned consortium

The ledger runs across nodes operated by known, admitted members. There is no public mempool, no anonymous explorer and no unknown validator.

You already know this as: a private network between counterparties you have onboarded, closer to a shared clearing utility than to a public blockchain.
Both gates ship off

The two banking features - issuance capacity and settlement - are implemented, tested, and disabled by default. An administrator has to deliberately turn each one on.

You already know this as: a feature flag on a release you have not yet approved. Present in the build, inert until signed off.

What actually changes

Wrong party

The envelope gives a governed reversal path a native state transition instead of leaving recovery entirely to external operations.

Unclaimed funds

AUTO_REVERSE can make the default outcome "nothing happened" when no recipient accepts the transfer in time.

Screening changes

Rules can be evaluated at network, institution, and wallet scope without creating a second ledger of exceptions.

Audit review

The issuer, terms, and lifecycle are part of the record rather than reconstructed later from disconnected systems.

The honest summary. This is a technical preview and a reference implementation, not a production-audited product and not a proposal to replace anything you run. It is a worked argument - in code you can read - that programmable money can carry banking's existing controls instead of asking you to abandon them. The open legal and compliance questions are published alongside it rather than left out.
Architecture lessons

What the design had to unlearn.

The important turns are the constraints that forced simplification, not the number of features accumulated.

Reversibility has a gas price

A governed reversal window means holding per-transfer state for the length of that window. On Ethereum mainnet that made the core premise uneconomic, which is why the contracts moved to Avalanche and the fee logic was rebuilt around it. A safety feature nobody can afford to use is not a safety feature.

Compliance surfaces change; contracts must too

Rules, jurisdictions and counterparties all move. A monolithic contract turns each change into a redeployment and a balance migration. The Diamond standard (EIP-2535) made facets individually replaceable without touching stored balances — and made contract-size limits a permanent constraint to engineer around.

The right privacy layer was no privacy layer

Built for a public chain, the design accumulated masked balances, commitment-only events and blinding primitives. On a permissioned consortium there is no public mempool, no anonymous explorer and no untrusted validator — so that machinery was removed rather than ported. Deleting sophisticated work is harder than adding it.

A risk engine banks can actually switch on

Transfers are scored against weighted rules at three scopes — network, institution and wallet - with Merkle-proof allow and deny lists so screening lists scale without bloating on-chain storage. An observation mode scores everything and blocks nothing, so an institution can shadow-run the engine against real traffic before it stops a single payment.

What is deliberately still open

The published release documents its gaps rather than omitting them. Both banking feature gates ship off by default. The admin UI, the payments gateway and the MCP tooling were held back from v1.0.0 as not yet release-caliber and are tracked as open issues with scoped effort estimates. The legal and compliance questions a deployment would need to answer are catalogued in the repository, not buried.

That is the contribution on offer: not a protocol to adopt, but a worked example of the trade-offs — published somewhere people can disagree with it.

Agentic payments

The same control problem arrives through AI.

If autonomous systems can initiate spend, the rail needs bounded authority, fail-safe defaults, intervention windows, and attribution.

Envelope lifecycle A transfer is created as an envelope with a commit window. If the recipient accepts within the window it finalises. If the window closes with no acceptance, an AUTO_REVERSE envelope returns the funds to the sender. Transfer created as an envelope Commit window open reversible · disputable screened against rules accepted window closes, no acceptance Finalised settled, no longer reversible AUTO_REVERSE funds return to sender Nothing happened the safe default
The failure mode is the important part: when an agent — or a person — gets it wrong and nobody accepts the transfer, an AUTO_REVERSE envelope ends with the money back where it started rather than gone.

Payments that default to undone

Every envelope declares an expiration behaviour. AUTO_REVERSE means a transfer that is not affirmatively accepted within its window reverses itself — the failure mode is "nothing happened", not "money is gone". HOLD_UNTIL_MANUAL keeps funds in escrow pending explicit release, and ORACLE_CONDITIONAL gates release on an external callback. An agent can be given the fail-safe behaviour by default and the finalising one only where a human has signed off.

Authority you can scope and rate-limit

The rules engine scores transfers at three scopes — network, institution and wallet — so an agent's wallet can carry its own weights, its own allow and deny lists, and its own velocity window without changing policy for anyone else. Caps are first-class: daily ceilings, outstanding-value limits and a configurable velocity window already exist because banks needed them, not because agents did.

Shadow-run before you delegate

Observation mode scores every transfer and blocks nothing. Point an agent at a consortium devnet, let it run, and read what the engine would have stopped — before it has the authority to stop anything. Delegating spend to a non-deterministic system without that rehearsal step is not a policy anyone should sign off on.

Attribution that survives the handoff

Every issuance is attributed to a specific institution and every envelope records its issuer, so "which agent, acting for which institution, moved this" is answerable from the ledger rather than reconstructed from logs. Agents also do not need to hold gas: ERC-2771 meta-transactions let a relayer submit on their behalf, so an agent's key authorises intent without also being a funded account.

What is not ready for agents, stated plainly

The component that would actually let an AI agent drive these contracts — an MCP server exposing them as tools — exists and was deliberately held back from v1.0.0. Its write path currently defaults to enabled with no allowlist, no confirmation step and no caps, which is the wrong default for any tool an autonomous system can call. Hardening that is tracked in the open rather than quietly shipped.

The claim here is narrow and deliberate: the primitives an agentic payment rail needs are implemented and tested, because a fraud-recovery system needs the same ones. The agent-facing surface on top of them is not finished. Both halves of that are worth knowing.

Review the design with us.

For banks, fintech architects, counsel, and builders who want to challenge the envelope model before anyone talks about activation.

Request a Review Session
Email the team at jesse@t3token.io to schedule a session.
Connect with T3Token on LinkedIn
Follow our leadership updates on LinkedIn
Explore the Code
Start with the public repository at github.com/jessedh/t3, then send the issues you want to debate.

Need technical documentation?

Access the white paper, API references, and integration guides tailored for engineers and compliance teams.

Visit Developer Docs