ARCOS: What a Module Is, and Why We’re Building One — Ownership Module v0.5 → v1.0
Why we’re doing this
ERC-721 gives you ownerOf() — a single address, a single static fact. That’s enough for provenance and transfer, but it can’t express anything richer: possession vs. use vs. benefit as separate, independently-held rights, delegation, custody, fractional ownership. Every project that wants an NFT to do more than sit in a wallet ends up solving this on its own, and the same failure modes repeat across the ecosystem:
- Fragmented — capabilities like delegation, custody, and rental are each covered piecemeal by separate, non-cooperating ERCs (e.g. three different delegation proposals that don’t interoperate, three competing rental standards). The ERCs themselves are fine; nothing coordinates between them once a project needs more than one.
- Custom, one-off — every project re-derives its own logic for these capabilities from scratch.
- Frozen at deployment — once shipped, that custom logic can’t gain a new capability or change an existing one without a redeployment and migration.
- Non-reusable, non-composable — the coordination one project builds can’t be picked up by the next, and two capabilities on the same token, built as bespoke code, have no shared layer to resolve conflicts through.
ARCOS is a governed coordination layer meant to close that gap — not by replacing the ERCs that already solve pieces of this well, but by originating the missing state and coordinating everything through one shared layer (we call it MAS — Module Activation System) instead of each project wiring its own.
What a Module is
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.
Every Module answers six fixed questions — universal questions, domain-specific answers:
- State/Structure — what it owns, and what that state means
- Authority — who can cause that state to change
- Transitions — how the state legitimately changes
- Invariants/Rules — what must hold true before and after a change
- Lifecycle & History — how the state exists and evolves over time
- System Interaction — how the rest of the system reads and triggers this state, exclusively through MAS
Beyond those six, a Module may adopt additional mechanisms — recovery paths, versioning, staged transitions — only where its own domain actually needs them. That’s a deliberate design rule, not an omission: one Module needing Recovery doesn’t mean the next one does.
This produces four properties, as an outcome of answering the six questions well rather than as a checklist designed toward directly:
- Governed — the whole path runs through the state machine, no way around it
- Reusable — any ARCOS-native NFT can adopt the Module without assembling custom logic
- Composable — Modules connect only through MAS, never directly to each other
- Evolvable — capabilities evolve; the governed-state model and six-question structure stay fixed underneath
Ownership Module: our first Module, v0.5
Ownership was the first domain we built out to full depth, because ownership itself — possession, use, benefit, transfer, exclusion — is the most fundamental thing ERC-721 leaves under-modeled. We built v0.5 as a working prototype (Next.js/TypeScript, with MAS running off-chain) covering the Ownership Module and four capabilities: Delegation, Shared Ownership, Custody, and Rental.
v0.5 proved the concept end to end at the application layer — real state transitions, real capability logic, running against actual NFT data. It also surfaced the real architectural questions we’re now resolving for v1.0: which parts of this need to be enforced on-chain versus coordinated off-chain, how state should be structured so new capabilities don’t require schema changes, and how a token’s owner can recover from a lost key without the whole capability system needing to be redesigned around that one case.
Now: v1.0
We’re currently working through the Ownership Module’s full specification — formalizing the Governed State model, locking down the Authority/Transition/Invariant pattern so every state change is checked before it’s written, and deciding the on-chain enforcement model (a token minted natively through ARCOS, rather than an external wrapper around an existing NFT contract — we found that wrapping an existing contract can’t actually be enforced, since the owner can always bypass it by calling the base contract’s transferFrom directly).
Ownership is the only Module built to this depth so far. Permission, Metadata, Verification, Royalty, Composition, and Economic & Incentive [royalty/discount/loyalty/mebmbership/rewards/benefits/incentives/revenue sharing] –are scoped at the same six-question framework but not yet built out — Ownership is the proof that the framework holds, not the finished product.
We’ll be posting the deeper Ownership Module design (Governed State fields, Authority, Capabilities-as-computed-reads) as a follow-up — this post is the “what and why” behind it. Github link: GitHub - payalhanda348-bot/ARCOS---STGF · GitHub