Directional Transfer Domain Registry - candidate ERC

ERCs
1

We would like feedback on a candidate ERC for a token-agnostic registry of directional transfer-route permissions between opaque domains by asset class.

Token standards and compliance modules commonly answer address-level or token-level questions. They do not provide a shared lookup surface for a separate policy question that can apply across many tokens:

Is transfer from this source domain to this destination domain currently permitted for this asset class?

A domain may represent a jurisdiction, regulated venue, enterprise network, game economy, DAO treasury boundary, or another application-defined context. The proposal deliberately treats domain and asset-class identifiers as opaque bytes32 values rather than prescribing one universal taxonomy.

Routes are keyed by the ordered triple:


(sourceDomain, destinationDomain, assetClass)

Direction is material. Permission from A to B does not imply permission from B to A. Asset class is also material, so the same pair of domains can permit one class and reject another.

The core interface supports route lookup, route-state retrieval, setting, immediate revocation, nonzero evidence commitments, and bounded batch queries. An optional graceful-revocation interface supports initiation, cancellation, future effectiveness, and finalization. A graceful revocation becomes effective at its announced timestamp even if no finalization transaction is submitted; finalization persists the state and emits the terminal event.

Scope boundaries

The registry evaluates only the supplied route triple. It does not:

  • assign accounts or tokens to domains;

  • define domain or asset-class taxonomies;

  • perform holder identity, balance, freeze, sanctions, or settlement checks;

  • validate the evidence behind a route decision; or

  • enforce token transfers by itself.

A token, compliance module, bridge, settlement contract, or transfer controller must resolve the applicable identifiers and query the registry inside the same transaction as the governed action. ERC-165 support indicates only that an interface is exposed; it does not prove that a token consults the registry or enforces its decisions.

Questions for review

  1. Is an opaque, application-defined domain namespace the right abstraction, or does interoperability require a separate standardized resolver interface?

  2. Is asset-class scoping sufficient, or are additional route dimensions needed in the base key?

  3. Should nonzero evidence commitments be mandatory for every permission and revocation action?

  4. Are immediate revocation and optional timestamp-based graceful revocation the right lifecycle split?

  5. Should graceful finalization be permissionless when effectiveness is already determined lazily by time?

  6. Are batch queries useful in the standard interface, and should the ERC set a universal maximum size or leave the bound implementation-defined?

Implementation status

A Solidity reference implementation and test suite is available at audited commit caa9b05. It includes immediate and graceful registries, unit and fuzz tests, and Medusa property tests. The implementation has also been reviewed in an independent Verichains audit.

This interface is independently deployable and token-standard-neutral. It was introduced alongside five other standalone interfaces in an earlier architecture discussion, but none of them is required to use this registry.

Authorship

Chris Turner, David Hay (LinkedIn), Reagan Simpson, and Collins Musyimi.

Developed at Kula, which builds infrastructure for regulated virtual-asset and titled-asset use cases. Reference implementations are open-source; we are proposing ecosystem interfaces, not a Kula-only stack. We are open to additional co-authorship and community contribution beyond Kula.

The formal ERC submission is available here:

1 Like