Skip to main contentA-REX Core

Записи о решениях · ADR-003

ADR-003: Adopt ERC-7943 (multi-token variant) verbatim for enforcement

Freezing, forced transfers and eligibility come from ERC-7943, copied verbatim, so that liens, seizures and embargoes have the shape compliance tooling already recognizes.

Accepted
Идентификатор документа
ADR-003
Дата
2026-09-21
Источник
docs/adr/ADR-003.md
Доступно только на английском
Этот документ опубликован на английском языке. Главы whitepaper и диаграммы переведены; нормативный стандарт, руководства по системному проектированию и записи о решениях остаются на английском, чтобы существовал единый авторитетный текст.
FieldValue
IDADR-003
Subject areaEnforcement
StatusAccepted
Date2026-09-21
OwnersA-REX Contributors
Related requirementsFR-05, FR-06, NFR-06 (SDD §3)
Supersedes / superseded by—

Context

Real lots are pledged to lenders, seized by courts, embargoed by sanctions and recalled by health authorities. A token that cannot freeze units or move them without the holder's signature cannot represent a warehouse receipt, a pledge or a recall. ERC-7943 (universal RWA interface) reached Final status in May 2026 and defines an ERC-1155 variant with interface id 0x41c4fbad; compliance engines and custody platforms target it.

Issue

Should A-REX define its own enforcement functions or adopt an existing interface, and which one?

Assumptions

  • ERC-7943 is Final and its multi-token variant fits ERC-1155.
  • Lenders, custodians and regulators will evaluate enforcement through tooling that already speaks ERC-7943.

Constraints

  • Must work on ERC-1155.
  • Must not prescribe an identity system (ADR-013).

Alternatives considered

AlternativeForAgainstOutcome
Bespoke freeze / seize functionsExactly tailoredNo tool recognizes them; every integrator writes an adapterRejected
ERC-3643 semantics on ERC-1155Familiar to security-token issuersERC-3643 is ERC-20 only and prescribes ONCHAINID and a compliance contractRejected
ERC-7943 multi-token variant, verbatimFinal, minimal, multi-token, already targeted by toolingA-REX inherits its exact semantics (for example, freezing beyond the balance is allowed)Accepted

Decision

IERC7943MultiToken is copied verbatim into contracts/standard/ and is REQUIRED for a conformant token. The interface id 0x41c4fbad is checked by the tests and printed by npm run interface-ids.

Argument

Enforcement is where interoperability matters most, because the parties that exercise it (courts, lenders, custodians) will not integrate a bespoke interface per issuer. Adopting a Final standard verbatim costs nothing and buys recognition.

Consequences

Positive

  • Compliance and custody tooling recognizes the enforcement surface without adapters.
  • canTransfer gives wallets a standard pre-flight answer.

Negative

  • The semantics are not ours to change; a disagreement with ERC-7943 must be resolved upstream.

Obligations it creates

  • canTransfer must reflect pause, eligibility, batch status, frozen balance and every CHECK hook.
  • Forced transfers follow ADR-012.

Implementation and evidence

WhatWhere
Interfacecontracts/standard/IERC7943MultiToken.sol
Freeze and forced transfertest/standard/ARexToken.test.js: frozen units cannot be moved by the holder, freezing more than the balance is allowed, forcedTransfer moves frozen units…
canTransfer equals the outcometest/standard/Invariants.test.js
  • ADR-002: ERC-1155 as the base token standard
  • ADR-005: bytes32 rejection codes instead of strings or hook-side custom errors
  • ADR-012: Forced transfers bypass pause and eligibility but still run hooks
  • ADR-013: Legal neutrality: the standard does not classify the token