FAQ


Is AON a blockchain?

No. Blockchains maintain shared mutable state: ownership, balances, transaction history. Consensus is required consensus 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.

Why doesn't AON need consensus?

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.

What determines truth?

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.

Who executes?

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.

Why would anyone execute?

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.

What happens if nobody executes?

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.

Can authorizations be revoked?

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.

Is AON a marketplace?

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.

Is AON replacing applications?

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.

What is a namespace?

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 defined by their implementations, not by the protocol. Anyone may define a new namespace. The network does not approve or reject namespaces. Adoption emerges through implementation and use.