An autonomous agent that transacts must be identifiable, owned, and answerable to a stated authority. On SWSS Chain that is a transaction class enforced by consensus, not a feature of the application that launched it.
Software that holds no identity of its own cannot be held to anything. An agent that values an asset, prices a contract or settles a payment is acting for someone, and if the only record of who that someone is sits inside an operator's database, the agent's authority ends where that operator's goodwill ends. Who owns this agent, what is it authorised to do, and has it acted before are then questions addressed to a company rather than to a record.
SWSS Chain answers them at the protocol. A Type 0x04 SCP Transaction registers an agent under the SWSS-AGENT- schema prefix, carrying an owner of record and an authority reference, and the protocol validates both before the transaction is admitted to the pool rather than trusting the application that submitted it. The difference from a registry deployed as a contract is not stylistic. A contract can be paused, replaced, or bypassed by deploying a second one beside it; a transaction class is applied by every validator on the network, and there is no deployment that routes around it.
What The Identity Record Carries
An agent is registered implicitly, on its first appearance on chain, and its record is maintained by the protocol from then on. There is no separate onboarding step that an operator could skip, defer, or perform on an agent's behalf after it has already transacted.
swss agent get <agentId>
agentId SWSS-AGENT-<reference> # the prefix is what classifies it ownerAddress the owner of record # indexed, so an owner's agents resolve together authRef DEED-<reference> # required, and required to be a deed reference registrationBlock first appearance on chain # an origin, not a claimed date registrationTxHash the registering transaction # checkable without asking the operator invocationCount maintained by the protocol # per-invocation, not per-session
There is no token identifier in this record, and its absence is the design rather than a gap. An identity is a registration; the transferable instrument is a separate record under a separate transaction class. A reader who finds a token identifier attached to an agent identity is reading something other than this registry.
Authority Is Anchored, Or There Is No Agent
Every Type 0x04 transaction carries an authority reference, and the protocol requires that reference to be a deed reference. The requirement is enforced when the transaction is admitted to the pool, which means an agent submitted without a stated authority is not an agent that gets rejected later or flagged for review: it never reaches the chain at all. There is no partially registered state, and no window in which an unanchored agent exists on the network while something catches up with it.
The consequence is worth stating plainly, because it is unusual. On SWSS Chain an agent cannot exist unanchored. Its identity is bound from its first block to an owner and to a stated authority, and neither is optional, retrofitted, or held in an application's records. A counterparty verifying an agent is verifying the chain's own admission rule rather than a claim the agent's operator makes about itself.
The Identity And The Instrument Are Separate Records
The agent that acts and the deed that can be held are deliberately different records under different transaction classes. Keeping them apart means the transferable instrument confers no operating authority, and the operating entity is not itself the thing being traded — a separation that is close to impossible to reconstruct once two records have been merged into one.
| AI Agent Identity | AI Agent Deed | |
|---|---|---|
| SCP Transaction | Type 0x04 | Type 0x03 |
| What it is | A registration, one per agent | A settled deed under the DEED-1 Standard |
| What it establishes | Provenance, an owner of record, and a stated authority | The deed's terms, as settled and recorded |
| Offered for sale | No | Yes, as the deed class provides |
| Where it is created | Submitted to the chain from the platform that operates the agent | Issued through SWSS RWAX, the one registry that issues every deed class |
An integrator that queries the wrong class receives the wrong records, and the two are close enough in name that this is the most likely mistake to make against this part of the protocol. The classifying value is the prefix: an identifier beginning SWSS-AGENT- is an identity, and one beginning with a deed prefix is a deed. Both resolve from SWSS Chain's own schema registry rather than from any table published here, so an integrator stays correct as new classes ship.
Ordering In The Agent Lane
Agent transactions do not compete with ordinary network traffic for position. The transaction pool separates deed settlements, agent transactions and ordinary transfers into three lanes, serves the typed lanes ahead of ordinary transfers, and orders the two typed lanes by arrival time rather than by gas price.
swss txpool lanes --ordering
Arrival time is stamped by the pool when a transaction is admitted, before it is indexed, so position in a typed lane is fixed by when it arrived and not by what it offered to pay. This is an architectural property rather than a fairness policy: there is no fee that reorders lane 0 or lane 1, because the comparator that sorts them does not read one. Ordinary transfers keep gas-price ordering, which is the behaviour a general-purpose chain is expected to have and the reason the two orderings are separated rather than blended.
The claim this supports is narrow and worth keeping narrow: the execution position of an agent transaction cannot be bought. That is a property of the comparator that sorts the pool, which does not read a fee when it sorts a typed lane, rather than a policy the Foundation undertakes to apply. A policy can be revised by whoever administers it; this can be verified by anyone reading the ordering rule the network runs. For an agent economy in which many agents act on the same information within the same second, an ordering that responds to fees is an ordering that sells the advantage — which is the outcome the consensus protocol separates these lanes to prevent.
Where An Agent Lives
A working agent touches four layers of the ecosystem, and each owns exactly one thing. The separation is what allows an agent's identity to survive the platform that built it: no single layer holds enough to be the agent on its own.
swss agent stack --explain
Every dashed stage is one that cannot be performed yet, which is not the same as a product that does not exist. SWSS RWAX is live and issues deeds today — the AI Agent Deed is simply not yet among the classes it issues. SWSS InfraX and SWSS AI OwlX v1 are in development. Only the identity layer is complete: the transaction class runs on SwssChain mainnet 122605 and testnet 122606 today. A figure that renders a shipped capability and an unbuilt one identically is making a claim it has not earned. The ordering matters more than the timing: an agent is identified before it is tokenised, so the record of who owns an agent never depends on whether anyone has bought a share of it.
Hardware is SWSS InfraX, where the agent runs and where the compute it consumes settles against delivery. Intelligence is SWSS AI OwlX v1, the model and the platform on which an agent is built, specialised and operated. Identity is SWSS Chain, which registers the agent and fixes its owner and authority at the protocol. The instrument is SWSS RWAX, where an agent that is tokenised is issued as an AI Agent Deed alongside every other deed class, through the same registry and the same standard.
Reading the layers in order explains a property that is easy to miss: an agent is identified before it is tokenised, and it does not need to be tokenised at all. The record of who owns an agent therefore never depends on whether anyone has acquired a share of its revenue, and an agent whose deed changes hands does not thereby change what it is authorised to do. The Deed Indexer reads both classes and counts them apart, because they measure different things.
What This Section Does Not Claim
No number of registered agents is published here, and none should be inferred. A count is a value that is wrong the moment it is printed, and an agent economy is measured by what the protocol guarantees rather than by how many participants have arrived. The registry answers for itself over the network, and an integrator reads a count from the chain rather than from this document.
No agent status vocabulary is published either. The registry maintains a status value whose meanings are not part of any published interface, and printing an interpretation of it here would put this document ahead of the specification it describes — the same reason no validator count appears in the ecosystem section.
Finally, an identity confers no revenue rights. Provenance, an owner of record and a stated authority are what a Type 0x04 registration establishes; a claim on an agent's earnings is the separate instrument described above. Authority also remains with the member throughout: an agent can settle nothing its principal could not settle, a valid credential from the Identity Verification Layer is required, and the resulting record is the same chain record any other settlement produces. Autonomy in this ecosystem is autonomy inside a settlement layer that checks every party, not autonomy from it.
What is an AI Agent Identity on SWSS Chain?