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 verification. Those rules do not designate any participant as authoritative. A node run by anyone is equivalent to a node run by anyone else. Validity derives from the objects themselves, not from the identity of the participant propagating them.
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, nodes will support it and executors will compete to serve it. If an 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:csd-usdc and aon:evm-spot are first implementations.
They demonstrate the model. They are not privileged.
Any participant may define a new namespace by publishing a manifest and implementing support in a node. The reference node is one implementation. Any participant may write another. Alternative implementations are the mechanism through which the network becomes robust. A network that depends on a single implementation is fragile.
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.
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.