No. Blockchains maintain shared mutable state: ownership, balances, transaction history. Consensus is required because participants must agree on a canonical version of that state. AON does not maintain shared state. It propagates authorization-related objects. Truth remains local to the namespaces that produce it. There is nothing for participants to agree on at the network level, so consensus is not required.
Consensus exists to resolve disagreement about shared mutable state. AON does not coordinate shared mutable state. Objects are content-addressed and immutable; their validity derives from their contents, not from agreement among participants. A proof is valid or invalid according to the rules of its namespace, regardless of what any other node believes. Participants may hold different views of the object graph without creating conflicting realities. Visibility affects discoverability, not validity.
Truth remains local to namespaces. AON does not determine truth. A proof referencing a CSD payment is valid or invalid according to CSD's own rules. A proof referencing an Ethereum state is valid or invalid according to Ethereum. The network propagates the proof; the namespace defines whether it is sufficient. AON neither replaces nor supersedes external sources of truth.
Anyone. Execution is a permissionless role. Any participant who discovers an executable authorization graph, one where all required conditions and proofs are present, may perform the authorized transition. No assignment is required. No approval is required. The authorization itself is the permission. The executor exercises it rather than creates it.
Executors run as separate processes from nodes. They connect to a node via HTTP,
fetch objects, evaluate graphs locally using the aon-sdk package, and
submit receipts back to the node as plain objects. The node has no knowledge of
the executor.
Authorization objects embed executor fees. A participant authorizing a settlement specifies how much of the settlement amount is paid to whichever executor completes the transition. Executors compete to discover and act on executable graphs. The fee is the incentive; speed is the competition. Participants set fees high enough to attract executors. Executors prioritize graphs with higher fees relative to execution cost.
Nothing. Authorization does not expire the network; it expires on its own terms.
An authorization specifies a validity window. If no executor acts before
validBefore, the authorization expires and the graph becomes
non-executable. No harm is done. The participant may publish a new authorization
with a higher fee or different conditions if they still want the action to occur.
The network makes no guarantees of execution; it only makes execution possible.
Yes. A participant publishes a Revocation Object referencing the authorization by hash, signed by the original signer. Nodes that observe the revocation exclude the target authorization from executable graphs. On-chain settlement contracts enforce revocation independently. Revocation does not modify the original object; both objects persist in the network. The revocation supersedes the authorization in the eyes of nodes and executors that have observed it.
No. A marketplace matches buyers and sellers and facilitates transactions on their behalf. AON does none of this. It propagates authorization objects and makes executable relationships discoverable. Participants define what they permit. Executors discover and act on those permissions. The network does not intermediate, does not take custody, and does not facilitate. It propagates.
No. Applications, platforms, exchanges, and settlement systems continue to exist. AON does not replace them; it externalizes one specific thing: authorization. Rather than embedding permission inside those systems, authorization becomes an independently addressable object that can be propagated, verified, and consumed across systems. The systems themselves remain responsible for their own state, their own truth, and their own logic.
A namespace identifies the environment within which an object should be interpreted.
It defines what a valid authorization looks like, what constitutes sufficient proof,
and how execution should occur. Namespaces are implemented as independent packages
that satisfy the NamespaceDriver interface from the SDK. Anyone may
implement and publish a namespace. The network does not approve or reject namespaces;
adoption emerges through implementation and use.