AON is a protocol. It is not a platform, a service, or an organization. No participant has authority over the network. That includes its creator.
The protocol contains no mechanism through which any participant can exercise authority over another. There is no governance process, no privileged node, no committee that approves namespaces or certifies implementations.
Nodes follow shared rules for object construction and structural validation: hash integrity, schema version, required fields. Those rules do not designate any participant as authoritative. A node run by anyone is equivalent to a node run by anyone else. Semantic validity (whether an authorization is correctly signed, whether a proof satisfies a condition) is determined by namespace adapters and executors, not by the node.
A protocol that retained authority over its own participants would contradict its own premise.
The protocol evolves through implementation. New namespaces, new executors, new node implementations, new client libraries; any participant may build these without asking permission and without modifying the core protocol.
If a new namespace proves useful, executors will implement it and participants will use it. If an executor implementation is better than the reference, participants will use it. If a namespace fails to attract participants, it will not be used. There is no process for approving or rejecting any of this. Merit and adoption are the only selection mechanisms.
aon-namespace-csd-usdc and aon-namespace-evm-spot are
first implementations. They demonstrate the model. They are not privileged.
Any participant may implement a new namespace as a package satisfying the
NamespaceDriver interface from the SDK. No changes to the node are
required. Executors import and register the package. The node propagates objects
in that namespace without knowing what they mean. Alternative namespace
implementations are the mechanism through which the protocol becomes useful across
more systems.
AON does not depend on its creator. It does not depend on any specific node, operator, or implementation. The protocol is defined by its rules, not by the software that first implemented them. The network continues as long as participants find it useful and choose to run nodes.
Participants coordinate through objects. Objects are valid or invalid according to rules that no single participant controls. The network persists through use, not through administration.
The network does not maintain shared mutable state. There is no canonical chain, no global ledger, no authoritative server. Every node that holds an object is equally authoritative about that object. Hash identity is derived from content; it does not live anywhere and cannot be destroyed.
Each transport is an independent failure domain. If internet connectivity is lost, LoRa and Bluetooth continue propagating objects within their physical range. If a radio module fails, libp2p and WebSocket continue over the internet. A node can run all transports simultaneously. Objects arriving over LoRa are forwarded to internet peers in the same operation, and vice versa.
The network survives as long as any two nodes can reach each other through any transport.
Participation requires no approval. Run a node. Write an executor. Define a namespace. Build a client. Implement the protocol in a different language. Any of these exists independently and adds to the network without needing to be accepted or endorsed by anyone.
The reference implementation is a starting point, not the definition of the protocol. The protocol is defined by the object model, propagation rules, and namespace semantics described in the original paper.