ARCOS Module —
Why this exists, briefly
ERC-721’s ownerOf() answers a static question — who owns this — with one address. Capabilities beyond that (delegation, custody, rental, verification) get solved piecemeal, as separate ERC extensions and custom per-project code, with nothing coordinating them once a project adopts more than one. The ERCs themselves are sound; the gap is coordination. That’s the problem a Module is built to close. This post is about the Module itself — the reasoning above is context, not the main argument here.
What a Module is
A Module is governed, reusable, composable, evolvable infrastructure — not a collection of capabilities bolted onto a contract. It’s one coherent domain of a digital asset’s behavior, built once as reusable machinery instead of welded per-project into each NFT contract.
A Module is a governed state machine — one structured domain of state, owned by exactly one authority, changed only through defined transitions, reachable by the rest of the system only through MAS.
A capability is what a Module can do. The Module is the machinery that determines how, when, and under whose authority that capability operates.
The six fixed questions
Every Module answers the same six architectural questions. The questions are universal — every Module gets asked all six, no exceptions. The answers, and whether a given mechanism is even needed, are domain-specific.
1. State/Structure — what the Module owns, and what that state means. Not “what data does it store” generically, but specific, named fields, each mapped to a real fact. A Module that can’t name its fields precisely hasn’t been designed yet. Ownership: five fields — Shares, Possession, Use, Benefit, Version.
2. Authority — who can cause that state to change. Not a stored flag, but a rule for computing, at any moment, exactly one answer to “whose action is legitimate right now.” It has to be live, not cached — if Authority can go stale, everything built on top of it inherits that staleness. Ownership: majority-holder-of-Shares, recomputed on every check.
3. Transitions — how the state legitimately changes. A finite, named set of ways State is allowed to move, each with its own preconditions — not “any write the contract permits.” Ownership: mint, delegate, revoke, move-to-custody, return-from-custody, recover.
4. Invariants/Rules — what must hold true before and after a change. Distinct from Authority: Authority asks who, Invariants ask whether this specific change is valid given who they are. A caller can be fully authorized and still attempt an invalid Transition — this check runs second, never first.
5. Lifecycle & History/Provenance — how the state exists and evolves over time. History is the append-only record of every past Transition. Lifecycle is a derived read over that record — never a separately stored status flag.
6. System Interaction — how the rest of ARCOS reads and triggers this state, exclusively through MAS. No Module calls another directly — this is what keeps each Module’s correctness independent of every other Module’s internal changes.
Why exactly six: each is load-bearing for the others. Drop State and there’s nothing to govern. Drop Authority and anyone can write. Drop Invariants and any authorized write is valid regardless of consequence. Drop History and there’s no way to audit how you got here. Drop System Interaction and Modules silently couple to each other.
What isn’t universal
Beyond the six, a Module may adopt additional mechanisms — recovery paths, versioning, staged transitions, time-bound state — only where its own domain needs them. A Module whose state is issued and later invalidated (an attestation) may need no recovery at all. A Module whose state represents a claim that can be lost or contested may need one. Both are correct for their own domain — decided by the domain, not by precedent from another Module.
The four properties
Outcomes of answering the six questions well, not inputs generating them: Governed (the whole architecture runs through the state machine, no path around it), Reusable (any NFT can adopt the Module without assembling custom logic), Composable (Modules connect only through MAS, never directly), Evolvable (capabilities evolve; the governed-state model and six-question structure stay constant underneath).
MAS: the only path between Modules
No Module calls another directly. MAS routes every entry, aggregates checks when an operation needs input from several, and enforces no duplicate state — if one Module’s state answers a question another needs, the second queries the first through MAS rather than holding its own copy.
How this actually runs, end to end
The six questions describe what a Module must answer. Here’s how those answers chain together at runtime, on the Ownership Module specifically — because this isn’t just architecture on paper; we built it and ran it.
Governed State — the five fields. Capabilities — never stored, just patterns read off those fields on demand, which is what makes two capabilities structurally unable to disagree about who holds what. Authority Root — the live computed answer to “whose action is legitimate right now,” the reference point every Capability is measured against. Transition — one of the named, legitimate ways State can move. Invariant — runs second, after Authority: is this specific change valid, given who’s asking. Lifecycle & History — every successful Transition emits an append-only log entry; Lifecycle is a derived read over it, never stored. Recovery/Failure closes the loop two ways: a failed Invariant check reverts the entire call — no partial write, nothing to point to, which is just checks-before-effects, not a separate mechanism — and Recovery is the one Transition gated by a different Authority (guardian quorum) for when the ordinary Root can’t act at all.
We ran this full chain, not just described it. One NFT, Sunset #7: minted to an owner, delegated to a gallery for 30 days, a collision attempt (trying to also send it to custody mid-loan) reverts with zero state change, the loan expires and Use auto-reverts, the piece moves to physical custody, and finally two of three guardians co-sign a recovery to a new wallet after the original key is lost. Every step happened as an actual transaction against a real local Ethereum node, not a diagram. Compiled clean with solc, zero warnings.
v0.5 → v1.0
v0.5 was the first built version — a working prototype (Next.js/TypeScript, MAS running off-chain) proving the Module concept through the Ownership domain and four capabilities: Delegation, Shared Ownership, Custody, Rental. It answered whether the concept works end to end at the application layer.
v1.0 is the better-specified architecture built from what v0.5 exposed: the Authority → Invariant → Transition pattern locked down precisely enough to implement on-chain, the enforcement model resolved (native mint through ARCOS rather than wrapping an existing contract, since wrapping is bypassable), and Governed State’s structure under active review as more capabilities get added. v1.0 is the architecture stage, not yet a deployed on-chain build.
Status
This framework has been validated against one domain: Ownership. The other planned Modules (Transfer, Permission, Metadata, Verification, Royalty, Composition, Security) are scoped at this framework but not yet built out to the same depth. Composable and Evolvable are demonstrated as design intent; they haven’t been proven across more than one Module yet.
I’m building this solo. Mentioning that plainly because it matters for how to read this post — this is one person’s architecture work under open scrutiny, not a funded team’s finished product. Disagreement and hard questions are the reason for posting this here, not an afterthought.
Question for Magician:
Given the six questions are fixed but the mechanisms are domain-specific, what’s actually the best way to test whether a Module is built correctly before it ships? Ownership got tested by running one asset through mint → delegate → collision → expiry → custody → recovery and checking that every failure reverted with zero partial state. Is that trace-and-verify approach sufficient for validating a Module, or is there a more rigorous method — formal verification of the Invariants, property-based testing against the state machine, something else — that this kind of infrastructure should be held to before it’s trusted with real assets? If you’ve built or audited a state-machine-style contract, what test would have caught something ours didn’t?