Authorization Object Network

A distributed object propagation network for authorized state transitions.

Most coordination systems retain authorization. Assets are deposited before trading. Permissions are stored before future execution. Authority accumulates inside the coordinating layer whether or not that was the intention.

AON externalizes authorization into independently addressable objects that propagate across a peer-to-peer network. Execution emerges when authorization, conditions, and proofs form a satisfiable graph. No system retains permission on behalf of participants. Independent systems can coordinate without transferring control to the coordinating layer.

Coordination no longer requires institutions.

Object model

Authorization: explicit, signed permission for a bounded action.
Condition: a requirement that must be satisfied before execution.
Proof: evidence that a condition has been met.
Receipt: a record that execution completed.
Revocation: a signed declaration that an authorization is no longer valid.
Namespace Manifest: defines the execution semantics for a namespace.

Objects beyond these five primitives, such as reserves, are namespace-specific implementations, not protocol requirements.

Namespaces

AON does not define business logic. Namespaces define it. The network transports objects; namespaces determine what those objects mean and how execution occurs.

Two namespace packages are available: aon-namespace-csd-usdc for cross-system settlement between CSD on Compute Substrate and USDC on Ethereum, and aon-namespace-evm-spot for non-custodial EVM spot trading. Namespaces are independent packages; anyone may implement and publish a new one without modifying the node or SDK.

Participate

Run a node: store and propagate objects, discover executable graphs.
Write an executor: discover opportunities, execute transitions, collect rewards.
Define a namespace: specify authorization semantics for a new environment.
Build a client: publish authorizations on behalf of users.

Resources