ADR-026: Networks

A-REX Core stays an EVM standard: the token and its rules run on EVM networks, and any EVM network at the paris level or later can host a conformant token. Networks are named by CAIP-2 ids. The evidence around a token is made chain-agnostic by a separate anchoring layer; there is no port of the standard to Solana or another non-EVM network.

Context

A-REX Core is written as an ERC. It requires ERC-165, ERC-1155 and ERC-7943; conformance is defined by ERC-165 interface ids; topics and codes are keccak256 values; rules are contracts called through IARexHook; and the upstream array of the batch metadata names another token's batch by EIP-155 chainId and a 20-byte contract address. The reference implementation (arex-contracts) is Solidity compiled for the paris EVM version, and its conformance suite tests an implementation on an EVM, with nothing specific to one network.

Implementers and their customers ask two different questions. The first is "can the token run on network X?", for example a cheaper or more neutral EVM rollup, or a non-EVM network such as Solana, Hedera or Stellar that is faster or cheaper per transaction. The second is "will the proof outlive the network?": lots, certificates and reports have to be provable ten or more years after the harvest, longer than any single network, operator or vendor can promise.

The A-REX Platform measured what a non-EVM port means. On Solana there is no ERC-1155, no ERC-165 and no ERC-7943; a lot would become a Token-2022 mint, which takes a single transfer-hook program, so the ordered hook pipeline (ADR-004) needs a dispatcher; "conformant" needs a new definition without interface ids; and every contract, the conformance suite and the custody model are rewritten. The estimate is 45 to 65 engineer-weeks plus a second audit, and every later rule, fix and change of the standard is then written, tested and audited twice. Storing a lot's state on Solana also costs a refundable deposit per byte, so it is not cheaper than an EVM rollup for this use case. The other non-EVM candidates (Stellar, Algorand, Cardano, Sui, Aptos) need a comparable rewrite. Hedera has an EVM of its own, whose differences in gas and accounts are not yet measured.

Issue

Should A-REX Core claim neutrality across network families, and how can the evidence a token produces remain checkable independently of the network the token is on?

Assumptions

• The interfaces, events, interface ids and codes of the standard are EVM concepts; restating them for another virtual machine is a second standard, not a profile of this one.
• Evidence needs only 32 bytes per period on another network to be anchored there; it does not need the token's state.
• Time and existence can be proven by any network that orders and timestamps data and keeps it public.

Constraints

• No change to an interface, event, error, interface id or MUST of AREX-CORE.
• No personal data on any network (ADR-008), wherever a root is published.
• Which networks an organisation may use is policy, not part of the standard (ADR-019).

Alternatives considered

Decision (proposed)

1. The token stays EVM. A-REX Core is an EVM standard (ADR-001, ADR-002). A conformant token, its hooks and its attestation registry run on an EVM network. The standard does not define a profile for any other virtual machine.
2. Any EVM network at the required level qualifies. A network that executes the EVM at the paris hard fork level or later (the opcodes the reference implementation is compiled for) can host a conformant token. Conformance is a property of the implementation, shown by the conformance suite, not of the network it is deployed on. The standard keeps no list of networks; which ones an organisation may use is set by its jurisdiction or organisation profile (ADR-019).
3. Network ids are CAIP-2. Where the standard or its informative formats name a network, they use the CAIP-2 chain id: eip155:<chainId> for EVM networks, and the namespace's own form elsewhere (bip122:… for Bitcoin, hedera:mainnet). The EIP-155 chainId integer stays where it already is (upstream[].chainId), and the two always agree.
4. Anchoring is a separate, chain-agnostic layer. An issuer MAY publish, once per period, a Merkle root over the fingerprints of its records on any number of networks, EVM or not, and give each record a proof that anyone can check with no A-REX service. The format is interop/ANCHORING.md (arex.anchor-proof/1, informative): domain-separated leaves (AREX:ANCHOR:LEAF:1), a sorted-pair Keccak-256 tree that OpenZeppelin MerkleProof verifies, and payloads for EVM networks, Bitcoin through OpenTimestamps and the Hedera Consensus Service. A token never reads an anchor, and an anchor adds no requirement to a token.
5. Lineage may cite a batch on another network. Batch metadata schema 1.4.0 (Proposed) adds an optional CAIP-2 network to each upstream entry. An EVM entry keeps chainId, contract and tokenId (and network, when given, is eip155:<chainId>); an entry for a batch recorded on a non-EVM network gives network and the batch's CAIP-19 asset instead. AREX-CORE §3.5 and §8 apply unchanged: an upstream entry is a claim of the issuer that verifiers check against the upstream record.
6. No Solana port. This record is reopened only on evidence: a signed customer or a regulator requiring lots as tokens on a named non-EVM network, or a failure that makes the EVM networks in use unusable for a long period.

Migration: none. Every token, hook, document and test that conforms today still conforms.

Argument

The standard is valuable because two implementers can build the same thing from it and a buyer can check the result with tools that already exist (ERC-165, ERC-1155 indexers, explorers, the conformance suite). Claiming neutrality across virtual machines would give up that property without delivering it. What customers need from other networks is mostly permanence and independence of the proof, and 32 bytes per period on several networks gives that at almost no cost, without moving the token or doubling the work. The anchoring format reuses the commutative Merkle proof that EVM contracts already verify, so a proof checks the same way off-chain and on-chain. CAIP-2 is the established, namespace-neutral way to name a network, and it lets one document cite an EVM chain, Bitcoin and Hedera without inventing ids.

Consequences

Positive

• An implementer knows exactly where a conformant token can run: any EVM network at the paris level or later.
• Evidence (audit logs, reports, documents, field records) can be proven years later even if the token's network, the issuer or its vendor is gone.
• A lot can name an input recorded on another network in a standard form.

Negative

• A customer who requires the token itself on a non-EVM network is not served by the standard.
• An anchor proves that a record existed unchanged at a time; it does not carry the token's state to the other network, and it does not prove the record is true.
• Implementers who anchor take on one more format and, per network, a small driver and its keys.

Obligations it creates

• interop/ANCHORING.md is kept exact: every constant and byte layout, with an example vector reproduced by an independent implementation.
• Batch metadata schema 1.4.0 (Proposed) carries upstream[].network and upstream[].asset; validators check, beside the schema, that an EVM entry's network equals eip155:<chainId>.
• A new network family for the token would need a new record that supersedes this one.

Implementation and evidence

Related decisions

• ADR-001: only the specification and the interfaces are normative
• ADR-002: the token model is ERC-1155, an EVM standard
• ADR-008: no personal data on the ledger, and therefore in no anchor
• ADR-019: which networks an organisation may use is policy in its profile
• ADR-022: EAS copies, the EVM-only way to make records readable by other tools