9 documents
System design
System Design Document, audit-readiness package, engineering guides.
These pages describe the reference implementation: requirements, components, operations, security controls, and the path from a requirement to a test. They are engineering records of that implementation.
| Document | Read it when you need to |
|---|---|
| System Design Document (AREX-SDD-001) | understand the whole system and trace any requirement to code and tests |
| Architecture summary (AREX-ARCH) | explain the design in one page |
| Audit readiness (AREX-AUD-001) | scope and prepare a security audit |
| Hook development (AREX-HOOK) | write, test and register a hook |
| Getting started, Development, Testing, Configuration | set up, change, test and configure the repository |
| Project structure | find where anything lives |
Access
You can use these pages to understand the shape of the reference system. Writing a hook, deploying a token, or reading an interface uses the repositories.
Companies that want to implement A-REX, issue batches with it, or audit it request read access on Request early access. Each request is reviewed by hand. Approved readers receive read-only access to the standard repository and the reference implementation.
Documents
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
A-REX Architecture — one-page summary
The full design — context, requirements, component model, data model, sequence diagrams, operational model, security controls, measured performance, decision records and the traceability matrix — is in SYSTEM DESIGN.md.
Audit Readiness Package
This document is what an external auditor receives on day one: scope, build instructions, invariants, threat model pointers, test coverage matrix, known limitations and the questions we want answered. It does not replace
Writing an A-REX hook
A hook is the only extension point of an A REX Core token. If you can express a rule as "given this operation on this batch between these accounts, allow or return a code", it is a hook.
Getting started
Node.js 20 or 22 LTS and npm. Clone and install from the lockfile:
Development
See PROJECT STRUCTURE.md. In one line: standard/ and contracts/standard/ are the standard; contracts/reference/ is the reference implementation (token, attestations) with the demonstration hooks and extensions.
Testing
Use Node.js 20 or 22 LTS with npm; the committed package lock.json is the source of truth for dependency versions. Newer Node majors may print Hardhat support warnings.
Configuration
Keep secrets in a local .env (see .env.example) or a secret manager. Never commit keys.
Project structure
Nothing in contracts/standard/ imports anything else in the repository; hooks and extensions depend on the interfaces, never on ARexToken.