Skip to main contentA-REX Foundation

Diseño del sistema · 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
ID del documento
AREX-SDD-001
Versión
2.0
Fecha
2026-09-21
Disponible solo en inglés
Esta página está en inglés. Los capítulos del whitepaper y los diagramas están traducidos. El texto normativo del estándar se mantiene en el repositorio; para leerlo, solicita acceso anticipado. Las guías de diseño del sistema y los registros de decisiones están solo en inglés.

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
mermaid
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
mermaid
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
mermaid
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
    }
mermaid
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
mermaid
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)
mermaid
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
mermaid
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
mermaid
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