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
- ID del documento
- AREX-SDD-001
- Versión
- 2.0
- Fecha
- 2026-09-21
- Fuente
- docs/SYSTEM-DESIGN.md
0. Document control
| Field | Value |
|---|---|
| Document ID | AREX-SDD-001 |
| Title | A-REX Core — System Design Document |
| Version | 2.0 |
| Status | Baseline for v2.0.0-alpha.2 |
| Date | 2026-09-21 |
| Owner | A-REX Contributors |
| Reviewers | Standard maintainers; external auditor (pending) |
| Classification | Public |
| Supersedes | the architecture notes of the previous code base (2025-10) |
0.1 Change history
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2025-10 | A-REX team | Architecture of the previous code base (monolithic token + capability modules) |
| 2.0 | 2026-09-21 | A-REX Contributors | Redesign as A-REX Core: standard/reference tiers, hook pipeline, ERC-7943, lineage, attestations; domain hooks and extensions; ADRs, RTM, RAID added |
| 2.1 | 2026-09-21 | A-REX Contributors | Previous code base and its adapter removed from the repository; documentation cleaned |
0.2 Related documents
| ID | Document | Location |
|---|---|---|
| AREX-SPEC | Normative specification (ERC format) | standard/AREX-CORE.md |
| AREX-SCHEMA | Batch metadata JSON Schema | standard/schema/batch-metadata.schema.json |
| AREX-ADR | Architectural decision records | docs/adr/ |
| AREX-AUD-001 | Audit readiness package | docs/AUDIT-READINESS.md |
| AREX-HOOK | Hook development guide | docs/HOOK-DEVELOPMENT.md |
| AREX-REV | Critical review that motivated A-REX Core (Spanish) | docs/history/REVISION-ESTANDAR-2026.md |
| AREX-SEC-2026-07 | July 2026 security review of the previous code base | docs/history/SECURITY-AND-STANDARDIZATION-REVIEW-2026.md |
| AREX-WP | Whitepaper (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 .-> VAULT8.3 Environments
| Environment | Purpose | Notes |
|---|---|---|
| Local (Hardhat) | development, tests, gas | npm test |
| Testnet (Sepolia) | integration with wallets/indexers | .env RPC and key |
| L2 production (Polygon, Arbitrum, Base, Optimism) | commercial deployments | cheapest; public |
| Permissioned EVM | issuers under strict data-protection or institutional requirements | same 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
| Procedure | Steps |
|---|---|
| Add a rule | deploy hook → review → registerHook (order matters) → publish getHooks() |
| Incident (bad hook) | pause → removeHook → investigate → unpause; forced transfers remain available |
| Lawful order | enforcement multisig → setFrozenTokens / forcedTransfer with order reference in data → events archived |
| Recall | lab attests → setBatchStatus(id, 255, reason) → indexer forward-traces via BatchTransformed |
| Upgrade | validate with OpenZeppelin plugin → timelock → upgradeToAndCall → smoke tests |
9. Security design
Controls by threat (details in the whitepaper Security Framework and AREX-AUD-001):
| Threat | Control | Component |
|---|---|---|
| Malicious/buggy hook blocks transfers | removable by HOOK_ADMIN_ROLE; pause; forced transfers unaffected; ERC-165 and flags checked at registration | CMP-01 |
| Hook re-entrance | storage lock across the sequence | CMP-01 |
| Compromised enforcement key | multisig; events; hooks may require order references | CMP-01, governance |
| Compromised upgrader | multisig + timelock; ERC-7201; plugin validation | CMP-01 |
| Status abuse | role only; disclosed; events with reason | CMP-01 |
| Issuer fraud | attributable issuer/originRef/metadataHash; independent attestations gate transfers | CMP-01, CMP-02, CMP-05 |
| Metadata substitution | role-gated; history in events | CMP-01 |
| Personal data exposure | normative originRef rule; restricted pointer | standard, schema |
| Stale sanctions | TTL and source per designation | CMP-03 |
| Delivery settlement spoofing | parties, batch and amount must match the delivery | CMP-08 |
| Oracle manipulation | quorum, median, per-round single submission per reporter | CMP-10 |
| Unbacked carbon claims | registry immobilisation records; attestation only | CMP-11 |
10. Non-functional realization
10.1 Performance (measured, Hardhat, 2026-09-21)
| Operation | 0 hooks | 1 hook (Eligibility) | 2 hooks (+Expiry) |
|---|---|---|---|
createBatch | 264,096 | 283,831 | 299,396 |
| transfer (cold) | 80,687 | 108,266 | 136,682 |
| transfer (warm) | 66,790 | 91,166 | 119,582 |
transform 1→2 | 564,422 | 595,707 | 636,858 |
setFrozenTokens | 54,188 | 54,188 | 54,188 |
forcedTransfer | 80,152 | 89,909 | 99,569 |
burn | 66,621 | 83,001 | 93,395 |
Warm transfer with exactly one hook of each kind:
| Hook | Gas | Δ vs. no hook |
|---|---|---|
| EligibilityHook | 91,166 | +24,376 |
| ExpiryHook | 92,023 | +25,233 |
| SeasonalHook | 94,324 | +27,534 |
| PerishabilityHook | 97,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
| ID | Decision |
|---|---|
| ADR-001 | Standardize interfaces only |
| ADR-002 | ERC-1155 base |
| ADR-003 | ERC-7943 verbatim for enforcement |
| ADR-004 | Single hook interface, cached flags, ordered evaluation |
| ADR-005 | bytes32 rejection codes |
| ADR-006 | Open codes, no enumerations |
| ADR-007 | Lineage through atomic transform |
| ADR-008 | No personal data on-chain |
| ADR-009 | Attestations in a companion contract |
| ADR-010 | Authority from roles; RETIRED terminal |
| ADR-011 | Pre-harvest as producedAt == 0 |
| ADR-012 | Forced transfers bypass pause/eligibility, run hooks |
| ADR-013 | Legal neutrality |
| ADR-014 | Carbon as registry-immobilised wrapper |
| ADR-015 | Oracle rounds by number |
| ADR-016 | UUPS + ERC-7201 + per-file optimizer |
Full records in docs/adr/.
12. Requirements traceability matrix
| Requirement | Component(s) | Verification | Decision |
|---|---|---|---|
| FR-01 | contracts/standard/* | repo structure; standard/README.md | ADR-001 |
| FR-02 | CMP-01 | conformance test (IERC1155 id) | ADR-002 |
| FR-03 | CMP-01 | batch tests (creation, pre-harvest, invalid) | ADR-006, ADR-011 |
| FR-04 | CMP-01 | lineage tests (split, merge, processing); INV-1 | ADR-007 |
| FR-05 | CMP-01, CMP-03 | freeze tests; eligibility tests | ADR-003 |
| FR-06 | CMP-01 | forced transfer test (frozen, sanctioned, paused) | ADR-003, ADR-012 |
| FR-07 | CMP-01 | ordering, rejection, data-forwarding tests; INV-6, INV-7 | ADR-004 |
| FR-08 | CMP-04 … CMP-09 | hooks read msg.sender token; domain hook tests | ADR-004 |
| FR-09 | CMP-01, ARexCodes | transferCheck assertions across tests | ADR-005 |
| FR-10 | CMP-01 | status tests; INV-2, INV-3 | ADR-010 |
| FR-11 | CMP-02 | attestation tests | AREX-SPEC §6 |
| FR-12 | CMP-11 | carbon wrapper test | ADR-014 |
| FR-13 | CMP-10 | oracle test | ADR-015 |
| FR-14 | CMP-08 | delivery tests; INV-11 | — |
| FR-15 | CMP-09 | traceability test | — |
| FR-16 | CMP-12 | insurance test; INV-14 | — |
| NFR-01/02 | CMP-01 | gas report (§10) | ADR-004 |
| NFR-03 | CMP-01 | forced-while-paused test | ADR-012 |
| NFR-04 | standard, schema | spec text; schema restricted | ADR-008 |
| NFR-05 | CMP-10, tests | oracle test; seeded invariants | ADR-015 |
| NFR-06 | CMP-01 | interface ids test | ADR-002, ADR-003 |
| NFR-07 | CMP-01 | size check (24,136 B) | ADR-009, ADR-016 |
| NFR-08 | CMP-01 | upgrade test; plugin validation | ADR-016 |
| NFR-09 | build | npm ci; CI workflow | — |
| NFR-10 | CMP-01 | ReentrantHook test; INV-5 | ADR-004 |
13. Risks, assumptions, issues, dependencies (RAID)
| ID | Type | Description | Mitigation / owner |
|---|---|---|---|
| R-01 | Risk | Interfaces change after production feedback | major version + migration note; no ERC submission before Phase 1 |
| R-02 | Risk | Hook governance key compromise | multisig + timelock; removal and pause procedures |
| R-03 | Risk | Legal classification differs per jurisdiction | ADR-013; counsel per offering |
| R-04 | Risk | Metadata unavailable | issuer SLA; hash guarantees integrity only |
| R-05 | Risk | No external audit yet | AREX-AUD-001 prepared; audit before production anchor |
| A-01 | Assumption | Issuers have access to legal registries (EWR, CPR-e, DDS, carbon) | referenced, not replaced |
| A-02 | Assumption | An eligibility provider exists per deployment | hook interface only |
| D-01 | Dependency | OpenZeppelin 5.3.0 | pinned |
| D-02 | Dependency | ERC-7943 Final text | copied 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)
| Contract | Bytes |
|---|---|
| ARexToken | 24,136 |
| ARexAttestations | 2,708 |
| EligibilityHook | 3,103 |
| ExpiryHook | 1,358 |
| AttestationHook | 1,873 |
| PerishabilityHook | 5,091 |
| SeasonalHook | 3,240 |
| DeliveryHook | 6,215 |
| TraceabilityHook | 4,076 |
| CommodityPriceOracle | 4,396 |
| CarbonImmobilizationWrapper | 4,588 |
| ParametricInsurance | 3,716 |