Whitepaper · 14
Future Developments
The roadmap from a frozen alpha interface to a de-facto and then an official standard, and the technical work that accompanies it. Dates are targets, not promises.
Principle
The interfaces are what gets standardized; everything else can evolve. The roadmap therefore has two tracks: standardization (make the interfaces trusted and adopted) and implementation (make the reference and the modules better without touching the interfaces).
Standardization track
| Phase | Target | Exit criteria |
|---|---|---|
| 0 · Alpha freeze (now) | v2.0.0-alpha interfaces published; reference implementation with all domain hooks and extensions; CI; specification in ERC format; system design document, decision records and audit package | no interface change without a major version |
| 1 · Production anchor (6–12 months) | one real deployment (cooperative, elevator or exporter) with real lots on an L2 or a permissioned chain | six months of operation; public metrics: batches, transformations, forced transfers executed, time to answer a traceability request; third-party audit published |
| 2 · Community (in parallel) | Ethereum Magicians thread; coalition of independent hook implementers; bidirectional ERC-3643 compliance adapter | three independent IARexHook implementations outside this repository; two independent conformant tokens |
| 3 · Submission | Draft ERC in ethereum/ERCs containing only standard/AREX-CORE.md (layers 1–3; ERC-7943 referenced, not copied) | editors' acceptance; Last Call without blocking objections |
| 4 · Neutral governance (year 2) | working group or association independent of the original authors; liaison with ISO TC 307 (the Spanish initiative on ERC-3643) and GS1 | governance documents adopted; specification maintained outside a single company |
Why not submit now: ERC-3643 was in production for three years before its EIP; ERC-7943 reached Final in eight months because its coalition already used it. An ERC freezes what it standardizes, and the interfaces deserve one production cycle before they are frozen for everyone.
Implementation track
Domain modules: ported (September 2026)
| Module | Now | Status |
|---|---|---|
| Perishability | PerishabilityHook (linear, exponential, step; per-commodity and per-batch config) + ExpiryHook | done |
| Seasonal | SeasonalHook | done |
| Delivery | DeliveryHook (state machine, cold chain, disputes, O(1) unit lock, settlement via transfer data) | done |
| Traceability | TraceabilityHook (EPCIS vocabulary; emit-only or persisted) | done |
| Sanctions, compliance | EligibilityHook (sanctions with source and TTL) | done |
| Transfer limits / quotas | not shipped; the Hook Development guide shows a bounded quota hook pattern | open (community) |
| Oracle | CommodityPriceOracle (rounds by number, quorum, median) | done |
| Carbon | CarbonImmobilizationWrapper (registry-immobilised credits; attestation; no issuance) | done |
| Insurance | ParametricInsurance (attestation-triggered) | done |
Remaining implementation work on these components is optimisation and production hardening, not design.
Settlement and financing primitives
- Holds and escrow (delivery-versus-payment): a hook plus a companion implementing conditional release; alignment with ERC-7573 where a payment leg is on-chain.
- Pledge workflow: a small contract that drives
setFrozenTokens/forcedTransferfrom a pledge agreement hash, so that lenders operate the enforcement role through an auditable procedure rather than raw calls.
Privacy
- Selective disclosure of quality data: zero-knowledge proofs that a measurement in the metadata document is within a limit (moisture, aflatoxin, residues) without revealing the value; the proof becomes an attestation.
- Restricted-data access control: reference implementation of the
restrictedpointer with capability tokens for buyers, certifiers and regulators.
Identity and attestations
- EAS-backed implementation of
IARexAttest. - Eligibility hook backed by ONCHAINID claims and by verifiable credentials (eIDAS 2.0 wallets).
Cross-chain
- ERC-7802 / CCIP wrapper reference; lineage remains on the home chain.
Tooling
- EPCIS 2.0 exporter over the event log.
- JSON Schema validator and RFC 8785 canonicalizer for metadata.
- Subgraph / indexer templates for batches, lineage, attestations and enforcement.
- Formal verification of the transfer pipeline invariants (supply conservation, terminal status, no re-entrance); a seeded randomized invariant test already exercises them (
test/standard/Invariants.test.js).
Research questions
- Whether
statustransitions should be expressible as an on-chain table (issuer-defined automaton) without bloating the standard. - Whether a standard account eligibility interface separate from hooks would ease integration with compliance engines, or whether the hook conjunction is enough.
- Mass-balance rules for processing (yield bounds per commodity pair) as hooks, and their interaction with legitimate losses.
- Reconciliation between on-chain lineage and physical commingling in silos, where "which kilogram" is legally a fungible claim.
What will not change
- The four interfaces, without a major version and a migration note.
- The rule that modules are demonstrations, not standard.
- The rule that personal data stays off-chain.
- The rule that authority comes from roles, not balances.