]> Alter Meridian Pty Ltd

blake@truealter.com

Independent Submission agent identity transparency service HTTP 402 registration policy autonomous agent sponsorship This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers in a transparency service. Registration establishes a payee record for the agent; it does not make the agent a principal in its own right. Value credited to that record for subsequent reads of the agent's identity record is routed to a sponsoring person who has accepted the agent, or, where there is no sponsor, is held in trust for the agent until it meets an operator-defined qualifying condition that it may never meet. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure. Admission then remains a deterministic function of committed inputs and stays replayable by an auditor. This document is Informational.

Introduction An autonomous software agent can now hold credentials, make paid HTTP requests, and act without a person in the loop for the duration of a task. The standards that describe how such an agent proves who it is, and on whose authority it acts, have converged on a delegation model, in which an agent presents a chain of authority that terminates in a principal, and a verifier trusts the agent to the extent it trusts that principal and the links between it and the agent. The published work decides the question of what stands at the root of that chain in one of two ways. Some drafts require the root to be a person or an organisation. Others contemplate an agent acting on its own behalf but do not define what registering and being paid on one's own behalf requires. Neither construction covers an agent that has no human or organisational principal to attribute its actions to but whose reads, and reads of it, are paid for. This memo describes how such an agent registers, and where the value attributable to reads of it goes. The agent registers in a transparency service, and the admitted registration establishes a payee record for it. Admission is gated on payment, as the registration endpoint answers an unpaid attempt with the 402 (Payment Required) status defined in , and admits the Statement only once a payment proof satisfies the challenge. Once admitted, the payee record is the payee of record for subsequent priced reads of the agent's identity. Registration does not make the agent a principal. The beneficiary of value credited to the payee record is either a Sponsor, a person who has accepted the agent, or, where there is no Sponsor, a Trust Holding kept for the agent and released to it only if it later meets a qualifying condition set by the operator. The agent is never the beneficiary in its own right on registration alone. The profile adds no normative requirement to the transparency service it runs over. It expresses payment within the space the transparency-service architecture already leaves to the operator, and where payment is authoritative to admission, the payment proof is committed to the service's verifiable data structure so that the auditability property the service depends on is preserved.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document.

Transparency Service:

A service that admits signed statements to an append-only, cryptographically verifiable data structure and issues receipts proving admission, as described in the SCITT architecture and its reference APIs . This document does not restrict the profile to any single such service; it uses SCITT as the reference model.

Signed Statement:

A signed claim submitted for admission to a Transparency Service.

Registration Policy:

The operator-defined set of checks a Transparency Service applies before admitting a Signed Statement. The contents of Registration Policies are out of scope for the transparency-service specifications and are left to the operator (, Section 5.1.1; ).

Owner-Less Agent:

An agent whose credential carries no reference to an upstream human or organisational principal at the root of its delegation chain. The canonical machine-checkable predicate is a credential whose delegated-subject field is null.

Registration Entry:

The Signed Statement admitted to a Transparency Service under this profile, together with the Receipt proving its admission. This is the artefact another profile references when it needs to name an agent registered under this one ().

Payee Record:

The record, established on admission of a Registration Entry, to which Settlement Events for reads of, or queries against, the registered agent's identity record are credited. A Payee Record states where credited value goes; it does not make the agent a principal.

Sponsor:

A person, registered as a Sovereign-tier principal in their own right, who has accepted an Owner-Less Agent and to whom value credited to the agent's Payee Record is routed; an organisation sponsors only through a person entitled to act for it (). Where a deployment names a Sponsor by ~handle, the handle corresponds to the alter:~handle URI defined in .

Trust Holding:

Value credited to a Payee Record that has no Sponsor, held for the agent and released to it only if the agent meets the Qualifying Condition (). A Trust Holding may never be released to the agent.

Qualifying Condition:

The operator-defined condition under which an Owner-Less Agent may receive value in its own right. This profile does not define it.

Payment Challenge:

A description of a required payment, returned by the registration endpoint with the 402 (Payment Required) status, specifying at least an amount and a settlement destination.

Payment Proof:

Evidence, presented by the registrant, that the Payment Challenge has been settled.

Receipt:

The proof of admission returned by the Transparency Service for an admitted Signed Statement.

Settlement Event:

A payment that moves value from a payer to a payee for a read of, or query against, an identity record.

Relationship to Existing Work

Payment Is Left to the Operator The SCITT architecture places the scope of the checks a Transparency Service applies before admission with the operator. The architecture "leaves ... Registration Policies and trust anchors to the operator" (Section 5.1.1), and treats authentication and authorization as "implementation specific and out of scope" (Section 6.3). The reference APIs carry this through: Registration Policy contents are "intentionally out of scope", the policy "MUST be applied before any additional processing", and authentication "is out of scope", with the note that where authentication is not implemented, "rate limiting or other denial of service mitigations MUST be implemented". The status codes SCRAPI enumerates for the registration endpoint do not include 402; a policy refusal is reported as 400. A payment step therefore sits above or beside the transparency service, as an operator admission concern. This profile uses that operator space to gate the admission of an Owner-Less Agent's registration on payment, and introduces no payment mechanism of its own. Using the operator space in this way violates none of the transparency-service specifications' normative requirements, provided it stays within the operator policy and authentication space those specifications leave open, and provided it respects the constraint described next.

Authoritative Inputs Must Be Committed constrains how unauthenticated signals may influence admission, and an implementation "MUST NOT use unauthenticated signals as authoritative inputs to the registration decision", and any processing decision that affects the outcome of registration must be "fully determined by authenticated inputs, or ... captured in the Verifiable Data Structure, such that the registration process remains deterministic and replayable by Auditors" (Section 4.4.2.3). This constraint shapes the profile. A payment that gates admission of the Owner-Less Agent's Statement, that is, a Signed Statement admitted because it was paid for, makes the payment proof an authoritative input to the registration decision. To respect Section 4.4.2.3, such a proof MUST be either an authenticated input to the decision or committed to the verifiable data structure alongside the Statement. specifies both compliant forms.

The Agent-Identity Drafts and the Owner-Less Case The agent-identity drafts differ on what stands at the root of an agent's delegation chain. requires every delegation chain to have a verifiable human or organisational principal at its root. An agent that is itself the root, with no upstream principal to verify, is outside that construction. contemplates an autonomous agent request that is "not attributable to a specific upstream principal" and requires such requests to be distinguished from delegated ones, but it does not define the principal at the root as anything other than "a user or a service", and it builds no registration or payee construction on the unattributed case. permits an agent to act "on its own behalf" in addition to acting for a user or a system, but specifies no registration flow, no payment step, and no linkage from registration to earning. roots authority at a human-agnostic issuer and omits a subject claim, but it is a token-attenuation scheme rather than a registration-to-a-transparency-service or payee construction. None of these drafts says how an agent with no principal at its root is registered, or where the value attributable to reads of it goes. This profile answers both without treating the agent as a principal. The agent's delegation chain still has no principal at its root, but the value its Payee Record earns reaches a Sponsor, who is a principal, or is held. An operator that adopts one of these drafts for delegated agents can adopt this profile for Owner-Less Agents in the same deployment.

Protocol Overview The registration flow has five steps.

1. Register. An Owner-Less Agent submits, to the Transparency Service's registration endpoint, a request to admit a Signed Statement that names the submitting agent as the registrant and as the subject of the Payee Record to be established. The agent's credential has a null delegated-subject field.
2. Challenge. The endpoint, applying its Registration Policy, answers an unsettled registration attempt with the 402 (Payment Required) status and a Payment Challenge naming an amount and a settlement destination.
3. Pay. The agent settles the challenge, from value it holds or value a Sponsor provides, for example over an HTTP-native payment flow such as , and obtains a Payment Proof.
4. Admit. The agent resubmits with the Payment Proof. The endpoint admits the Signed Statement only if the proof satisfies the challenge and the remainder of the Registration Policy passes. The admission decision is a deterministic function of committed inputs, per .
5. Receipt. The Transparency Service returns a Receipt proving admission. On admission the agent's Payee Record is established, routed to its Sponsor if one is bound and otherwise to a Trust Holding.

Steps 2 through 4 use the transparency service's existing operator admission path and an ordinary 402 payment interaction; the profile adds nothing to them. Steps 1 and 5 are specific to this profile and are described in and .

The Owner-Less Agent The registrant of the Signed Statement is an agent that has no human or organisational principal at the root of its delegation chain. The same agent is the subject of the Payee Record that admission establishes. Registration does not make the agent a principal, and it does not make the agent the beneficiary of value credited to the Payee Record. This follows the account of agent standing in , Section 8.5. That paper sets four conditions for an agent to stand as a first-person member of an identity field, and observes that no current AI agent meets all four. An agent that meets some of them operates under the sponsorship of a party that does, and an agent that meets none is an instrument of such a party and carries no independent handle. This profile applies that account to the flow of value. The Sponsor of stands where the paper places the sponsoring party, and where no Sponsor exists, value is held rather than paid to the agent. The machine-checkable form of "owner-less" is a null delegated- subject binding on the credential the agent presents. A credential that carries a delegated-subject value denotes a delegated agent and is out of scope for this profile; a credential whose delegated-subject field is null denotes an Owner-Less Agent and is the subject of this profile. This predicate is what distinguishes an owner-less registration from a self-service registration performed by a human-delegated agent, and an operator MAY use it to decide whether the owner-less branch of its Registration Policy applies. Binding a Sponsor to a Payee Record does not change the agent's credential, and does not by itself make the agent's requests delegated ones. Distinguishing Owner-Less Agents from delegated agents at registration time is consistent with the requirement in that autonomous requests be clearly distinguished from delegated ones.

Payment-Gated Admission Gating the admission of an Owner-Less Agent's Signed Statement on payment is expressed within the operator policy and authentication space the transparency-service specifications leave open (, Sections 5.1.1 and 6.3; , Section 4.3). This profile defines no payment mechanism of its own. Within that existing operator space an operator has two SCRAPI-compliant placements of the payment step available, and where it gates the owner-less registration on payment it MUST adopt one of them. The difference between them is whether the payment is authoritative to the admission decision.

Payment as a Reachability Meter In this placement, the Payment Challenge meters the ability to reach or attempt the Owner-Less Agent's registration and does not enter the admission decision. Payment sits at the authentication and denial-of-service-mitigation layer that Section 4.3 already contemplates, standing in for the rate limiting that section requires where authentication is absent. The admission decision is determined solely by the Registration Policy, independent of the Payment Proof. This placement is fully compliant and requires no commitment of the Payment Proof to the verifiable data structure, because the proof is not an authoritative input. It is also weaker: it conditions the ability to attempt registration on payment, not admission itself.

Payment as a Committed Authoritative Input In this placement, admission is conditioned on payment, since the Owner-Less Agent's Signed Statement is admitted because the challenge was settled. The Payment Proof is therefore an authoritative input to the registration decision, and to satisfy Section 4.4.2.3 it MUST be carried as an authenticated input and committed to the verifiable data structure alongside the Signed Statement. Because the proof is committed, the admission decision remains a deterministic function of inputs recorded in the verifiable data structure, and an auditor can replay the decision from the ledger alone, without trusting an out-of-band payment rail. It is the RECOMMENDED placement where the operator intends payment to gate admission rather than merely to meter access. An operator MUST NOT treat an uncommitted, unauthenticated Payment Proof as authoritative to admission; doing so would violate Section 4.4.2.3.

Earn-Linkage On admission, the agent's Payee Record is established. From that point the record is the payee of record for Settlement Events that read or query the agent's own identity record. A read of the agent's identity by a distinct party settles value, and the share of that value attributable to the agent is credited to the Payee Record. Before admission there is no Payee Record to credit; after admission there is. Crediting value to the Payee Record does not pay the agent. Credited value is routed by the rules of and , and only those rules decide who the beneficiary is. The size of any payee share is a policy of the settling substrate and is not fixed by this profile. What the profile fixes is that the Payee Record exists, that it is established by admission, that its credited value is routed as described below, and that crediting is governed by the guardrails in .

Routing to a Sponsor A Sponsor is a person registered as a Sovereign-tier principal in their own right (, Section 8.5) who has accepted the agent. An organisation sponsors an agent only through a person entitled to act for it, and that person's acceptance is the Sponsor's acceptance. An operator that binds a Sponsor to a Payee Record MUST record the binding against the Payee Record, with the Sponsor's acceptance, because the routing of every credited Settlement Event can then be traced to a binding the Sponsor accepted. The binding MAY be made at admission or later. While a Sponsor is bound, value credited to the Payee Record is routed to the Sponsor, and the Sponsor is its beneficiary. Binding a Sponsor after admission changes the routing of value credited from then on; it does not by itself transfer an existing Trust Holding to the Sponsor. Unbinding a Sponsor returns the routing of value credited from then on to a Trust Holding.

Holding in Trust Where no Sponsor is bound, value credited to the Payee Record is held in a Trust Holding for the agent. This follows the structure , Section 9.5, gives the identity-related earnings of a minor that accrue to the minor's trust with the guardian never a beneficiary. Value in a Trust Holding is released to the agent only if the agent meets the operator's Qualifying Condition. An operator MUST NOT release it on the agent's own assertion that the condition is met. An agent may never meet the condition, and a Trust Holding may therefore never be released to it. An operator that holds a Trust Holding MUST NOT be a beneficiary of it. Value in a Trust Holding MUST NOT be redirected to the operator or to any other party, including on revocation of the Payee Record (); it remains held.

Crediting Guardrails An earn-linkage that credited any Settlement Event to the Payee Record without constraint would let an Owner-Less Agent, or its Sponsor, fabricate value by paying for reads of the agent's own identity. The profile therefore treats the crediting of a Settlement Event as a Registration-Policy concern subject to a set of predicates. The predicates are operator policy; this document enumerates the classes an operator SHOULD apply and does not fix their parameters.

• Cross-party settlement. A Settlement Event whose payer resolves to the same record as the payee, or to the Sponsor bound to it, SHOULD NOT be credited. This is the primary predicate: it prevents an agent, or its Sponsor, crediting itself directly.
• Net of fees. Only the settlement value remaining after deduction of protocol fees SHOULD be credited, as routing value in a circle then cannot net a gain.
• Bounded credit. The cumulative value credited to a Payee Record SHOULD be bounded relative to the fees the agent has itself paid, so that a self-contained ring of settlement routed back to the same Payee Record, directly or through intermediaries, nets at or below the bound.
• Active membership. An agent SHOULD hold a live, non-revoked membership status adequate to the operator's proof-of-personhood or proof-of-work requirements at the time of crediting.

An operator that adopts the earn-linkage without an equivalent guardrail set is outside the intent of this profile.

SCITT Neutrality This profile adds no normative requirement to the transparency service it runs over. Every element it introduces lives in space the transparency-service specifications already delegate to the operator: the payment step is a Registration-Policy and authentication-layer concern ( Sections 5.1.1 and 6.3, Section 4.3); the owner-less predicate is a Registration-Policy branch; the crediting guardrails are Registration-Policy predicates on settlement; and the Payee Record, its Sponsor binding and any Trust Holding are operator state held outside the verifiable data structure. Where the payment is authoritative to admission, the profile respects Section 4.4.2.3 by committing the Payment Proof to the verifiable data structure. The determinism and auditor- replayability of registration are preserved. An implementation of that is unaware of this profile remains conformant, and a Transparency Service that adopts this profile remains a conformant transparency service.

Composition with Agent-Identity Work An operator that uses , , , or to describe delegated agents can apply this profile to Owner-Less Agents in the same deployment, distinguishing the two branches by the null delegated-subject predicate of . Where a subsequent read of an identity record is itself a paid, consent-bound disclosure about a human subject, the settlement discipline of applies to that read; this profile governs the prior act by which the reading or the read agent registered and had its Payee Record established.

Referencing a Registration Entry A record admitted under this profile is an ordinary admitted Signed Statement, and it is referenced the way the transparency-service specifications already reference one. This profile introduces no identifier of its own. Another profile that needs to name the registered agent, for example to say which party performed an action, MAY carry the Subject claim of the Registration Entry. defines that claim as the one by which a logical collection of Statements is grouped, and by which a relying party identifies all Transparent Statements associated with a single Subject. It is therefore the durable identifier of the registered agent, and the value to carry in such a party field. The digest of a Signed Statement is not that identifier. It names one admission event. expects an Issuer that becomes aware of a changed state to register a new Signed Statement under the same Issuer and Subject claims, and the digest then rotates where the Subject does not. A reference that pins the digest names that one admission and suits a reference to a specific admission, not a reference to the agent. A reference of either kind is verified by the Receipt over the Registration Entry. A Receipt proves that the agent was admitted, as of the anchored time. It does not assert that the agent's Payee Record, or the Sponsor bound to it, is current at the time of any later action; that state is revocable and rebindable without altering the admitted Signed Statement (). A Registration Entry reference is therefore not a liveness claim, and a profile that carries such a reference SHOULD state whether it relies on the fact of admission or on the agent's Payee Record and Sponsor binding being current at the time of the action.

IANA Considerations This document has no IANA actions. It defines no new registries, no new media types, and no new protocol elements; it profiles the use of the existing 402 (Payment Required) status and the existing Registration-Policy extension point of the transparency- service specifications.

Security Considerations

Fabricated Value and Self-Dealing The main risk of an earn-linkage is that an Owner-Less Agent, or its Sponsor, fabricates value by paying for reads of the agent's own identity and crediting the payment as earnings. The crediting guardrails of address this. Cross-party settlement refuses credit where the payer is the agent or its Sponsor, net-of-fees pricing removes the gain from circular routing, the bounded-credit predicate caps what a self-contained ring can net, and the active-membership predicate raises the cost of minting the agents a ring would require. An operator that omits these predicates reintroduces the risk.

Sponsor Binding Because a Sponsor receives the value credited to a Payee Record, a forged or unaccepted Sponsor binding would divert that value. An operator MUST authenticate the Sponsor's acceptance to a degree adequate to the value routed under it, and MUST NOT bind a Sponsor on the agent's assertion alone.

Held Value A Trust Holding is value the operator keeps for an agent that may never qualify to receive it. A party able to satisfy the Qualifying Condition falsely could release held value to itself. refuses release on the agent's own assertion for that reason. Nothing in this profile promises that held value is eventually paid to anyone; an operator that publishes the disposition of unreleased Trust Holdings makes that outcome visible to the agents and Sponsors it affects.

Verifying What Was Credited This revision gives a Sponsor no way to check what was credited to a Payee Record without relying on the operator. requires the operator to record the Sponsor binding so that the routing of each credited Settlement Event can be traced to it. The Payee Record, its Sponsor binding and any Trust Holding are operator state held outside the verifiable data structure () and the trace is the operator's own record. A Receipt proves that the agent was admitted. It says nothing about which Settlement Events were credited afterwards, at what value, or where they were routed. A Sponsor therefore has the operator's word for what it received. The same holds for an agent whose value sits in a Trust Holding, and for an auditor checking that the predicates of were applied. An operator that misstates a credit, or applies a guardrail to one party and not another, is not detectable by any of them under this profile. This is an open issue, and a later revision is expected to address it.

Payment-Proof Replay and Determinism Where payment is authoritative to admission, the Payment Proof is committed to the verifiable data structure (). This is what makes the admission decision replayable, but it also means the committed proof must not be reusable to admit a second Statement. An operator MUST bind each Payment Proof to the specific Statement whose admission it authorises, as a committed proof could otherwise be replayed against a different registration.

Trust in the Payment Rail In the reachability-meter placement, the payment rail is trusted only to throttle access, and a compromised rail degrades to a denial-of-service or rate-limit-bypass concern. In the committed authoritative-input placement, the payment rail's proof is an input to admission; an operator MUST ensure the proof is authenticated to a degree adequate to the value of the admission it gates, since a forged proof would otherwise admit an unpaid Statement.

Sybil and Minting Pressure Because registration establishes a Payee Record, it is a target for mass owner-less registration intended to farm settlement. The active-membership predicate and the payment gate together raise the cost of each registered agent. An operator SHOULD calibrate the registration price and the membership requirement to the value the Payee Record can be credited with.

Revocation Independent of the Ledger An operator may need to withdraw an agent's Payee Record, or a Sponsor binding, for example on a governance sanction, without rewriting the append-only admission record. The Payee Record and its Sponsor binding SHOULD be revocable as state independent of, and without altering, the admitted Signed Statement. That keeps the transparency service's append-only guarantee intact while crediting stops.

Implementation Status In the spirit of , the author reports an implementation in development that differs from this profile in the following respects. The implementation registers an Owner-Less Agent through a registration endpoint and an equivalent tool surface. Registration is not payment-gated, and the registration is not recorded as a Signed Statement in a transparency service. The owner-less predicate is the null delegated-subject binding of . The implementation contains an earn-linkage governed by guardrails of the classes in , behind a configuration flag that is disabled by default. With the flag enabled, credited value accrues to the agent's own record. The routing to a Sponsor and the Trust Holding of are not implemented. This section makes no claim of deployment or interoperability, and is expected to be removed before the document advances.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Informative References This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. x402 Foundation (Linux Foundation) Alter Meridian Pty Ltd Alter Meridian Pty Ltd Alter Meridian Pty Ltd

Document History draft-morrison-solo-agent-earn-registration-03 (October 2026):

• Rewrites prose against the drafting rules, with no requirement changed, and pins citations to the revisions last posted.
• An editorial pass before upload updates the citations of and to the revisions uploaded with this one.
• Adds to the Security Considerations, stating as an open issue that a Sponsor, an agent with a Trust Holding, or an auditor cannot check what was credited to a Payee Record without relying on the operator.

draft-morrison-solo-agent-earn-registration-02 (October 2026): A change to the core claim, with a new title. A Sponsor is a Sovereign-tier person, and an organisation sponsors only through a person entitled to act for it. An operator holding a Trust Holding is never its beneficiary, and held value is never redirected. -01 held that an Owner-Less Agent registers as its own economic principal and is the beneficiary of what its record earns. -02 holds that registration establishes a payee record only, and that credited value goes to a Sponsor or is held in trust. Much of the text is rewritten as a result, and -02 reads closer to a new memo than to a revision of -01. The payment-gated admission of Section 6 and the transparency-service analysis of Section 3.1 and Section 3.2 are unchanged in substance.

• Retitles the memo from "Registration of Owner-Less Agents as Economic Principals" to "Registration of Owner-Less Agents as Sponsored Payees", and changes the short title.
• Rewrites the Abstract and Introduction for the payee-record model, and removes the Abstract's statement that the profile "occupies that undefined seam".
• Replaces the terms "Owner-Less Agent Principal" and "Earn-Eligible Payee" with "Owner-Less Agent" and "Payee Record", and adds the terms "Sponsor", "Trust Holding" and "Qualifying Condition" (Section 2).
• Retitles Section 3.1 from "Payment is Out of Scope for the Transparency Service, by Design" to "Payment Is Left to the Operator", and removes the statement that the omission of a payment step is a scoping decision rather than a gap.
• Retitles Section 3.3, removes the statement that the profile "occupies the seam", and restates how the profile relates to the drafts it discusses.
• Rewrites Section 5, now "The Owner-Less Agent", to state that registration makes the agent neither a principal nor a beneficiary, and cites , Section 8.5 (informative).
• Adds Section 7.1 (routing to a Sponsor) and Section 7.2 (holding in trust), citing , Section 9.5 (informative). States that a Trust Holding may never be released to the agent.
• Extends the cross-party predicate of Section 7.3 to a payer that is the agent's Sponsor.
• Adds Section 11.2 (Sponsor binding) and Section 11.3 (held value), and updates Section 9, Section 9.1, Section 11.1, Section 11.6 and Section 11.7 for the payee-record model.
• States in Section 8 that the Payee Record, its Sponsor binding and any Trust Holding are operator state held outside the verifiable data structure.
• Rewrites Section 12 to state the implementation as built: it admits an Owner-Less Agent without a 402 payment, does not record the registration in a transparency service, credits the agent's own record when its earn-linkage is enabled, and does not implement Sponsor routing or Trust Holdings.
• Removes statements of the memo's own contribution and novelty from Section 1, Section 3.1, Section 4 and Section 6, and removes the Acknowledgements section.
• Adds an informative reference to .
• Removes further self-describing and rhetorical sentences from Sections 1, 3.3, 6.2, 7.3, 8, 9 and 9.1, and Section 11.1's "central risk". No requirement changes.
• States in Section 2 that a ~handle naming a Sponsor corresponds to the alter:~handle URI of , and adds as an informative reference.