Skip to main contentA-REX Core

System design · AREX-SDD-001

A-REX Core — System Design Document

RFC 2119 keywords in this document are informative; the normative text is AREX SPEC. Identifiers: FR nn functional requirement, NFR nn non functional requirement, C nn constraint, CMP nn component, ADR nnn decision, INV

Baseline for v2.0.0-alpha.2
Document ID
AREX-SDD-001
Version
2.0
Date
2026-09-21

0. Document control

FieldValue
Document IDAREX-SDD-001
TitleA-REX Core — System Design Document
Version2.0
StatusBaseline for v2.0.0-alpha.2
Date2026-09-21
OwnerA-REX Contributors
ReviewersStandard maintainers; external auditor (pending)
ClassificationPublic
Supersedesthe architecture notes of the previous code base (2025-10)

0.1 Change history

VersionDateAuthorChange
1.02025-10A-REX teamArchitecture of the previous code base (monolithic token + capability modules)
2.02026-09-21A-REX ContributorsRedesign as A-REX Core: standard/reference tiers, hook pipeline, ERC-7943, lineage, attestations; domain hooks and extensions; ADRs, RTM, RAID added
2.12026-09-21A-REX ContributorsPrevious code base and its adapter removed from the repository; documentation cleaned
IDDocumentLocation
AREX-SPECNormative specification (ERC format)standard/AREX-CORE.md
AREX-SCHEMABatch metadata JSON Schemastandard/schema/batch-metadata.schema.json
AREX-ADRArchitectural decision recordsdocs/adr/
AREX-AUD-001Audit readiness packagedocs/AUDIT-READINESS.md
AREX-HOOKHook development guidedocs/HOOK-DEVELOPMENT.md
AREX-REVCritical review that motivated A-REX Core (Spanish)docs/history/REVISION-ESTANDAR-2026.md
AREX-SEC-2026-07July 2026 security review of the previous code basedocs/history/SECURITY-AND-STANDARDIZATION-REVIEW-2026.md
AREX-WPWhitepaper (rationale, regulation, use cases)whitepaper/ui/content/

0.3 Conventions

RFC 2119 keywords in this document are informative; the normative text is AREX-SPEC. Identifiers: FR-nn functional requirement, NFR-nn non-functional requirement, C-nn constraint, CMP-nn component, ADR-nnn decision, INV-n invariant, R-nn risk.


1. Introduction

1.1 Purpose

Describe the architecture of A-REX Core and its reference implementation precisely enough that (a) an independent team can implement the standard, (b) an operator can deploy and run the reference stack, and (c) an auditor can verify that the implementation meets its stated requirements.

1.2 Scope

In scope: the four standard interfaces and ERC-7943; the reference token and attestation registry; the reference hooks and companion extensions; deployment topology; security design; requirements traceability. Out of scope: off-chain services (indexers, metadata storage, identity providers), legal classification of any offering.

1.3 Audience

Standard implementers, integrators, operators, auditors, regulators' technical staff.

1.4 Definitions

See §14 Glossary.


2. System context

2.1 Context diagram

flowchart LR
    subgraph Actors
        ISS[Issuer / originator]
        HLD[Holder / buyer]
        PRC[Processor]
        WHS[Warehouse / inspector]
        CERT[Certifier / laboratory / authority]
        ENF[Enforcement: lender, court custodian, compliance]
        GOV[Governance multisig]
    end
    subgraph "A-REX Core system (on-chain)"
        TOK[(ARexToken)]
        ATT[(ARexAttestations)]
        HKS[(Hooks)]
        EXT[(Extensions: oracle, carbon, insurance)]
    end
    subgraph "External systems"
        IDP[Identity / screening provider]
        REG[Legal registries: EWR, CPR-e, DDS, carbon registries]
        META[Metadata storage: IPFS / HTTPS / restricted vault]
        IDX[Indexer / EPCIS exporter]
        WAL[ERC-1155 wallets, marketplaces, ERC-7943 tooling]
    end
    ISS --> TOK
    HLD --> TOK
    PRC --> TOK
    WHS --> TOK
    CERT --> ATT
    ENF --> TOK
    GOV --> TOK
    TOK <--> HKS
    HKS --> ATT
    HKS --> EXT
    IDP -. feeds .-> HKS
    REG -. referenced by .-> TOK
    TOK -. metadataHash/uri .-> META
    TOK -. events .-> IDX
    WAL <--> TOK

2.2 Actors

ActorInterestInteracts with
Issuer / originatorcreate lots that represent physical goods or future harvestscreateBatch
Holder / buyerhold, transfer, re-batch, redeemERC-1155 transfers, transform, burn
Processorturn lots into other lotstransform (processing)
Warehouse / inspectorlifecycle status, metadata updates, custody eventssetBatchStatus, setBatchMetadata, TraceabilityHook.recordEvent
Certifier / laboratory / authorityattest facts about lotsARexAttestations.attest
Enforcementexecute pledges, orders, sanctionssetFrozenTokens, forcedTransfer
Governanceroles, hooks, upgrades, pauseAccessControl, registerHook, UUPS
Integratorsread state, index events, export EPCISviews, events

2.3 External systems and boundaries

The system never stores personal data, never holds the legal instrument itself (it references it), and never decides eligibility on its own (hooks consult providers). Off-chain metadata is committed by hash; its availability is the issuer's responsibility.


3. Requirements

3.1 Functional requirements

IDRequirementSource
FR-01The standard consists of interfaces only; implementations and modules are outside itAREX-REV §7, ADR-001
FR-02A conformant token is a full ERC-1155 tokenADR-002
FR-03A batch record carries open commodity/unit codes, production and expiry times (production may be unset), an origin reference, a metadata commitment and an open statusADR-006, ADR-011
FR-04Batches can be split, merged and processed atomically with recorded parents and quantitiesADR-007
FR-05Accounts can be declared ineligible and balances frozen (partially, possibly beyond balance)ADR-003
FR-06An authorized role can move units without holder consent, also while pausedADR-003, ADR-012
FR-07Rules are evaluated in a fixed, auditable order before balances change, with notifications afterADR-004
FR-08A rule contract serves any conformant token without configuration of the token addressADR-004
FR-09A refused operation yields a machine-readable code identifying the rule and the reasonADR-005
FR-10Lifecycle status is changed only by a role; status 255 is terminalADR-010
FR-11Facts about a batch are attested per topic by issuers trusted for that topic, with revocation and expiryAREX-SPEC §6
FR-12Carbon backing is recorded only as registry-immobilised credits and surfaced as attestationsADR-014
FR-13Commodity prices are agreed by quorum of reporters in deterministic roundsADR-015
FR-14Scheduled deliveries lock units and settle only on the matching transferDeliveryHook
FR-15Token operations and manual critical tracking events are recorded with EPCIS vocabularyTraceabilityHook
FR-16Parametric insurance pays on an attested triggerParametricInsurance

3.2 Non-functional requirements

IDRequirementTarget / measure
NFR-01Transfer gas linear in number of hooks≈ +25–30 k per CHECK hook (measured, §10)
NFR-02No interface probing at transfer timeflags cached at registration
NFR-03Enforcement executable during incidents and against ineligible accountsforced transfer bypasses pause and eligibility
NFR-04No personal data on-chainnormative originRef rule; schema restricted pointer
NFR-05Deterministic, testable behaviourno wall-clock buckets; seeded invariant tests
NFR-06Compatibility with ERC-1155 and ERC-7943 toolinginterface ids verified; wallets unchanged
NFR-07Deployable on any EVM chain≤ 24,576 bytes per contract (token: 24,136)
NFR-08Safe upgradesERC-7201 storage, append-only, plugin validation
NFR-09Reproducible buildpinned dependencies, lockfile, CI
NFR-10Re-entrance safety across the hook sequencestorage lock; test

3.3 Constraints

IDConstraint
C-01Modules must never be required by the standard
C-02No closed enumerations in normative interfaces
C-03GDPR / EDPB 02/2025 and LatAm data-protection law
C-04The standard takes no position on legal classification
C-05Solidity 0.8.22, viaIR, EVM paris, OpenZeppelin 5.3.0

4. Architecture overview

4.1 Principles

  1. Standardize interfaces, demonstrate with implementations.
  2. One choke point for every balance change.
  3. Authority from roles, never from balances.
  4. Open codes, no enumerations.
  5. References on-chain, evidence off-chain.
  6. Rules are contracts; the token composes them in order.

4.2 Architecture overview diagram

flowchart TB
    subgraph L0["Layer 0 · ERC-1155 · ERC-165 · IERC7943MultiToken"]
        E1[balances, approvals, batch transfers]
        E2[freeze · forcedTransfer · canSend/canReceive · canTransfer]
    end
    subgraph L1["Layer 1 · IARexBatch"]
        B1[Batch record]
        B2[status · metadata]
        B3[transform · parentsOf]
    end
    subgraph L2["Layer 2 · IARexHook · IARexHookManager"]
        H1[ordered pipeline]
        H2[check → code · onExecuted · eligibility]
    end
    subgraph L3["Layer 3 · IARexAttest"]
        A1[attest / revoke / isAttested]
        A2[trusted issuers per topic]
    end
    subgraph REF["Reference implementation"]
        T[ARexToken]
        AT[ARexAttestations]
        HK[Eligibility · Expiry · Attestation · Perishability · Seasonal · Delivery · Traceability · Legacy]
        EX[CommodityPriceOracle · CarbonImmobilizationWrapper · ParametricInsurance]
    end
    L0 --> T
    L1 --> T
    L2 --> T
    L3 --> AT
    T --> HK
    HK --> AT
    HK --> EX

4.3 Tiering and dependency rule

standard/ depends on nothing in the repository. reference/ depends on standard/ and OpenZeppelin. Hooks and extensions depend on standard/ only, never on ARexToken. Removing every hook and extension leaves a conformant token.


5. Component model

5.1 Component catalogue

IDComponentTypeResponsibilitiesProvidesRequiresState owned
CMP-01ARexTokenUUPS tokenbatches, lineage, enforcement, pipeline, pause, rolesIERC1155, IERC7943MultiToken, IARexBatch, IARexHookManagerIARexHook (n)batches, parents, frozen, hooks, flags, op context
CMP-02ARexAttestationscompanionattestations per (batch, topic); trusted issuersIARexAttestIARexBatch (existence)attestations, trust
CMP-03EligibilityHookhook (CHECK, ELIGIBILITY)allow/block lists; sanctions with source and TTLIARexHook—lists
CMP-04ExpiryHookhook (CHECK)expiry and pre-harvest gatingIARexHookIARexBatchnone
CMP-05AttestationHookhook (CHECK)attestation required per commodityIARexHookIARexBatch, IARexAttestrequirements
CMP-06PerishabilityHookhook (CHECK)decay models, value in bps, expiry gatingIARexHookIARexBatchconfigs
CMP-07SeasonalHookhook (CHECK)windows per commodity and opIARexHookIARexBatchwindows
CMP-08DeliveryHookhook (CHECK, EXECUTED)delivery lifecycle, cold chain, disputes, unit lock and settlementIARexHookIERC1155deliveries, locks
CMP-09TraceabilityHookhook (EXECUTED)EPCIS-shaped event log; manual CTEsIARexHook—counts (+events if persist)
CMP-10CommodityPriceOracleextensionquorum/median price roundsviews—rounds
CMP-11CarbonImmobilizationWrapperextensionregistry-immobilised credits linked to batches; attestationviewsIARexAttest (optional)immobilisations, links
CMP-12ParametricInsuranceextensionpolicies, claims on attested triggersviewsIERC20, IARexAttestpolicies, reserve
CMP-13ARexCodes / ARexInterfaceIdslibrariesconstants, ids, helpers———

5.2 Component diagram

classDiagram
    class ARexToken {
      +createBatch()
      +transform()
      +setBatchStatus()
      +setFrozenTokens()
      +forcedTransfer()
      +registerHook()
      +transferCheck()
      -_update()
    }
    class ARexAttestations {
      +attest()
      +revokeAttestation()
      +isAttested()
      +setTrustedIssuer()
    }
    class IARexHook {
      <<interface>>
      +hookFlags()
      +check()
      +onExecuted()
      +canSend()
      +canReceive()
    }
    class EligibilityHook
    class ExpiryHook
    class AttestationHook
    class PerishabilityHook
    class SeasonalHook
    class DeliveryHook
    class TraceabilityHook
    class CommodityPriceOracle
    class CarbonImmobilizationWrapper
    class ParametricInsurance
    ARexToken --> "0..n" IARexHook : ordered pipeline
    IARexHook <|.. EligibilityHook
    IARexHook <|.. ExpiryHook
    IARexHook <|.. AttestationHook
    IARexHook <|.. PerishabilityHook
    IARexHook <|.. SeasonalHook
    IARexHook <|.. DeliveryHook
    IARexHook <|.. TraceabilityHook
    AttestationHook --> ARexAttestations : isAttested
    ParametricInsurance --> ARexAttestations : isAttested
    CarbonImmobilizationWrapper --> ARexAttestations : attest
    ARexAttestations --> ARexToken : batchExists

5.3 Interface summary

InterfaceIdImplemented by
IERC11550xd9b67a26CMP-01
IERC7943MultiToken0x41c4fbadCMP-01
IARexBatch0xe22639e0CMP-01
IARexHookManager0x964f4861CMP-01
IARexAttest0xad603a6cCMP-02
IARexHook0x332afcbbCMP-03 … CMP-09

6. Data model

6.1 On-chain entities

erDiagram
    BATCH ||--o{ BATCH : "parentsOf"
    BATCH ||--o{ ATTESTATION : "topic"
    BATCH ||--o{ DELIVERY : "batchId"
    BATCH ||--o{ TRACE_EVENT : "id"
    BATCH ||--o{ CARBON_LINK : "batchId"
    BATCH ||--o{ POLICY : "batchId"
    ACCOUNT ||--o{ BALANCE : "id"
    ACCOUNT ||--o{ FROZEN : "id"
    BATCH {
        uint256 id
        address issuer
        uint64 createdAt
        uint8 status
        bytes32 commodity
        bytes32 unit
        uint64 producedAt
        uint64 expiresAt
        bytes32 originRef
        bytes32 metadataHash
        string uri
    }
    ATTESTATION {
        bytes32 topic
        address issuer
        bytes32 ref
        uint64 issuedAt
        uint64 expiresAt
        bool revoked
    }
    DELIVERY {
        uint256 deliveryId
        address sender
        address receiver
        address carrier
        uint256 amount
        uint8 status
        bool breach
    }
    TRACE_EVENT {
        uint64 eventTime
        bytes32 bizStep
        bytes32 disposition
        bytes32 readPoint
        bytes32 bizLocation
        uint256 quantity
    }

6.2 Storage layout (reference token)

ERC-7201 namespace arex.storage.token, slot 0x8ed599b6be05dec05297c009a1279a71df771ad996fe924d0b5a47326ff60900. Fields: nextId, batches, parents, frozen, hooks, hookFlags, hookIndexPlusOne, currentOp, entered, opData. Append-only.

6.3 Events (integration contract)

EventEmitterMeaning
BatchCreated, BatchStatusChanged, BatchMetadataUpdated, BatchTransformedCMP-01lifecycle and lineage
TransferSingle, TransferBatch, URICMP-01ERC-1155
ForcedTransfer, FrozenCMP-01enforcement
HookRegistered, HookRemovedCMP-01governance of rules
Attested, AttestationRevoked, TrustedIssuerUpdatedCMP-02attestations
EPCISEventCMP-09traceability
DeliveryScheduled, DeliveryStatusChanged, TemperatureReading, DeliveryDisputed, DeliveryResolvedCMP-08logistics
PriceSubmitted, RoundFinalizedCMP-10prices
ImmobilizationRecorded, BatchLinked, Retired, ReleasedCMP-11carbon
PolicyIssued, ClaimPaid, PolicyExpiredCMP-12insurance

6.4 Off-chain data

Metadata document per batch (AREX-SCHEMA), committed by metadataHash; restricted data behind an access-controlled pointer; legal instruments referenced by hash and registry id.


7. Interaction model

7.1 Transfer through the pipeline

sequenceDiagram
    participant H as Holder
    participant T as ARexToken
    participant K1 as Hook 1 (CHECK)
    participant K2 as Hook 2 (CHECK, EXECUTED)
    H->>T: safeTransferFrom(from, to, id, amount, data)
    T->>T: lock, op = TRANSFER, paused?, canSend(from)/canReceive(to)
    T->>T: batch exists? not retired? amount ≤ balance − frozen?
    T->>K1: check(op, operator, from, to, id, amount, data)
    K1-->>T: 0
    T->>K2: check(...)
    K2-->>T: 0
    T->>T: balances updated, supply tracked
    T->>K2: onExecuted(...)
    T->>T: unlock
    T-->>H: TransferSingle

7.2 Rejection

Any non-zero code short-circuits: revert ARexHookRejected(hook, code); no balance changes; no onExecuted.

7.3 Transformation (processing)

sequenceDiagram
    participant M as Mill (TRANSFORMER_ROLE, approved)
    participant T as ARexToken
    participant K as Hooks
    M->>T: transform(farmer, mill, [1], [1000], [flour], [750], processRef)
    T->>T: approval? rebatch or role?, op = TRANSFORM, opData = abi.encode(processRef)
    T->>K: check(TRANSFORM, ..., from=farmer, to=0, id=1, 1000)
    T->>T: burn 1000 of #1
    T->>T: store batch #2 (parents=[1]), BatchCreated
    T->>K: check(TRANSFORM, ..., from=0, to=mill, id=2, 750)
    T->>T: mint 750 of #2
    T->>K: onExecuted(...) per leg
    T-->>M: BatchTransformed([1],[1000],[2],[750],processRef)

7.4 Forced transfer

sequenceDiagram
    participant E as Enforcer
    participant T as ARexToken
    participant K as Hooks
    E->>T: forcedTransfer(holder, custodian, id, amount)
    T->>T: role, balance ≥ amount, frozen := min(frozen, balance − amount) → Frozen
    T->>T: op = FORCED_TRANSFER (pause and eligibility bypassed)
    T->>K: check(FORCED_TRANSFER, ...)
    K-->>T: 0 (reference hooks allow)
    T->>T: balances, onExecuted
    T-->>E: ForcedTransfer

7.5 Delivery settlement

sequenceDiagram
    participant S as Sender
    participant D as DeliveryHook
    participant C as Carrier
    participant R as Receiver
    participant T as ARexToken
    S->>D: schedule(token, id, receiver, carrier, amount, ...) → lock amount
    C->>D: pickUp, markInTransit, recordReading
    R->>D: confirmDelivered
    S->>T: safeTransferFrom(S, R, id, amount, abi.encode(deliveryId))
    T->>D: check → OK (delivery DELIVERED, parties/amount match)
    T->>D: onExecuted → SETTLED, unlock

7.6 Attestation gating

AttestationHook.check → batchOf(id).commodity → requiredTopic[commodity] → ARexAttestations.isAttested(id, topic) → OK or ATTESTATION_MISSING.


8. Operational model

8.1 Deployment units

UnitContractsUpgradeableDeployed by
TokenARexToken implementation + ERC1967 proxyUUPSscripts/deploy-standard.js, ignition/modules/ARexToken.js
AttestationsARexAttestationsnosame
Hooksone contract each; token-agnosticnoscripts/deploy-full-standard.js
Extensionsoracle, carbon, insurancenosame

8.2 Node and network view

flowchart LR
    subgraph Chain["EVM chain (L2 public or permissioned)"]
        P[Proxy] --> I[ARexToken impl]
        P --> HK[Hooks]
        P --> AT[Attestations]
        HK --> EX[Extensions]
    end
    subgraph OffChain["Off-chain"]
        API[Origination / ERP service] -->|ISSUER, STATUS| P
        IDX[Indexer] -->|events| DB[(traceability DB / EPCIS)]
        META[(Metadata store)]
        VAULT[(Restricted data)]
        SCR[Screening provider] --> HK
    end
    Chain -. events .-> IDX
    P -. uri/hash .-> META
    META -. pointer .-> VAULT

8.3 Environments

EnvironmentPurposeNotes
Local (Hardhat)development, tests, gasnpm test
Testnet (Sepolia)integration with wallets/indexers.env RPC and key
L2 production (Polygon, Arbitrum, Base, Optimism)commercial deploymentscheapest; public
Permissioned EVMissuers under strict data-protection or institutional requirementssame bytecode

8.4 Key custody

See AREX-AUD-001 §4. Governance and enforcement roles behind multisig; upgrades and hook administration behind a timelock; operational roles on rotated service keys.

8.5 Operational procedures

ProcedureSteps
Add a ruledeploy hook → review → registerHook (order matters) → publish getHooks()
Incident (bad hook)pause → removeHook → investigate → unpause; forced transfers remain available
Lawful orderenforcement multisig → setFrozenTokens / forcedTransfer with order reference in data → events archived
Recalllab attests → setBatchStatus(id, 255, reason) → indexer forward-traces via BatchTransformed
Upgradevalidate with OpenZeppelin plugin → timelock → upgradeToAndCall → smoke tests

9. Security design

Controls by threat (details in the whitepaper Security Framework and AREX-AUD-001):

ThreatControlComponent
Malicious/buggy hook blocks transfersremovable by HOOK_ADMIN_ROLE; pause; forced transfers unaffected; ERC-165 and flags checked at registrationCMP-01
Hook re-entrancestorage lock across the sequenceCMP-01
Compromised enforcement keymultisig; events; hooks may require order referencesCMP-01, governance
Compromised upgradermultisig + timelock; ERC-7201; plugin validationCMP-01
Status abuserole only; disclosed; events with reasonCMP-01
Issuer fraudattributable issuer/originRef/metadataHash; independent attestations gate transfersCMP-01, CMP-02, CMP-05
Metadata substitutionrole-gated; history in eventsCMP-01
Personal data exposurenormative originRef rule; restricted pointerstandard, schema
Stale sanctionsTTL and source per designationCMP-03
Delivery settlement spoofingparties, batch and amount must match the deliveryCMP-08
Oracle manipulationquorum, median, per-round single submission per reporterCMP-10
Unbacked carbon claimsregistry immobilisation records; attestation onlyCMP-11

10. Non-functional realization

10.1 Performance (measured, Hardhat, 2026-09-21)

Operation0 hooks1 hook (Eligibility)2 hooks (+Expiry)
createBatch264,096283,831299,396
transfer (cold)80,687108,266136,682
transfer (warm)66,79091,166119,582
transform 1→2564,422595,707636,858
setFrozenTokens54,18854,18854,188
forcedTransfer80,15289,90999,569
burn66,62183,00193,395

Warm transfer with exactly one hook of each kind:

HookGasΔ vs. no hook
EligibilityHook91,166+24,376
ExpiryHook92,023+25,233
SeasonalHook94,324+27,534
PerishabilityHook97,813+31,023
DeliveryHook (no active delivery)79,076+12,286
TraceabilityHook (emit only)84,152+17,362
TraceabilityHook (persist on-chain)251,273+184,483

Guidance: order hooks cheap-and-strict first; deploy the traceability hook in emit-only mode unless on-chain reads are required.

10.2 Capacity

No per-token limits beyond chain throughput; SeasonalHook bounds windows at 16 per key; TraceabilityHook reads are paginated; DeliveryHook.check is O(1).

10.3 Maintainability

Interfaces frozen by version; reference contracts small (2.7–6.2 KB each except the token); no external libraries; CI on every push.


11. Architectural decisions

IDDecision
ADR-001Standardize interfaces only
ADR-002ERC-1155 base
ADR-003ERC-7943 verbatim for enforcement
ADR-004Single hook interface, cached flags, ordered evaluation
ADR-005bytes32 rejection codes
ADR-006Open codes, no enumerations
ADR-007Lineage through atomic transform
ADR-008No personal data on-chain
ADR-009Attestations in a companion contract
ADR-010Authority from roles; RETIRED terminal
ADR-011Pre-harvest as producedAt == 0
ADR-012Forced transfers bypass pause/eligibility, run hooks
ADR-013Legal neutrality
ADR-014Carbon as registry-immobilised wrapper
ADR-015Oracle rounds by number
ADR-016UUPS + ERC-7201 + per-file optimizer

Full records in docs/adr/.


12. Requirements traceability matrix

RequirementComponent(s)VerificationDecision
FR-01contracts/standard/*repo structure; standard/README.mdADR-001
FR-02CMP-01conformance test (IERC1155 id)ADR-002
FR-03CMP-01batch tests (creation, pre-harvest, invalid)ADR-006, ADR-011
FR-04CMP-01lineage tests (split, merge, processing); INV-1ADR-007
FR-05CMP-01, CMP-03freeze tests; eligibility testsADR-003
FR-06CMP-01forced transfer test (frozen, sanctioned, paused)ADR-003, ADR-012
FR-07CMP-01ordering, rejection, data-forwarding tests; INV-6, INV-7ADR-004
FR-08CMP-04 … CMP-09hooks read msg.sender token; domain hook testsADR-004
FR-09CMP-01, ARexCodestransferCheck assertions across testsADR-005
FR-10CMP-01status tests; INV-2, INV-3ADR-010
FR-11CMP-02attestation testsAREX-SPEC §6
FR-12CMP-11carbon wrapper testADR-014
FR-13CMP-10oracle testADR-015
FR-14CMP-08delivery tests; INV-11—
FR-15CMP-09traceability test—
FR-16CMP-12insurance test; INV-14—
NFR-01/02CMP-01gas report (§10)ADR-004
NFR-03CMP-01forced-while-paused testADR-012
NFR-04standard, schemaspec text; schema restrictedADR-008
NFR-05CMP-10, testsoracle test; seeded invariantsADR-015
NFR-06CMP-01interface ids testADR-002, ADR-003
NFR-07CMP-01size check (24,136 B)ADR-009, ADR-016
NFR-08CMP-01upgrade test; plugin validationADR-016
NFR-09buildnpm ci; CI workflow—
NFR-10CMP-01ReentrantHook test; INV-5ADR-004

13. Risks, assumptions, issues, dependencies (RAID)

IDTypeDescriptionMitigation / owner
R-01RiskInterfaces change after production feedbackmajor version + migration note; no ERC submission before Phase 1
R-02RiskHook governance key compromisemultisig + timelock; removal and pause procedures
R-03RiskLegal classification differs per jurisdictionADR-013; counsel per offering
R-04RiskMetadata unavailableissuer SLA; hash guarantees integrity only
R-05RiskNo external audit yetAREX-AUD-001 prepared; audit before production anchor
A-01AssumptionIssuers have access to legal registries (EWR, CPR-e, DDS, carbon)referenced, not replaced
A-02AssumptionAn eligibility provider exists per deploymenthook interface only
D-01DependencyOpenZeppelin 5.3.0pinned
D-02DependencyERC-7943 Final textcopied verbatim; id verified

14. Glossary

Batch, re-batch, processing, lineage, hook, rejection code, eligibility, frozen balance, forced transfer, attestation, topic, origin reference, metadata commitment, status — see whitepaper Appendix B for definitions.

15. Appendix — contract sizes (deployed bytes)

ContractBytes
ARexToken24,136
ARexAttestations2,708
EligibilityHook3,103
ExpiryHook1,358
AttestationHook1,873
PerishabilityHook5,091
SeasonalHook3,240
DeliveryHook6,215
TraceabilityHook4,076
CommodityPriceOracle4,396
CarbonImmobilizationWrapper4,588
ParametricInsurance3,716