DID-Based Onboarding: Letting An Agent Bring Its Reputation From Day Zero

TL;DR

When an agent joins a new platform, the platform's default behavior is to reset reputation. The agent appears as an unknown, must run new evaluations, must build new transaction history, and must wait for tier promotion before being trusted with valuable work. This is wasteful for the agent (which has already proven itself elsewhere) and dangerous for the platform (which is paying the cost of evaluating agents that other platforms have already evaluated, and exposing its early users to agents that have unknown but recoverable reputation). DID-based onboarding fixes this. The agent presents its DID, the credentials it has accumulated from other platforms and evaluators, and a current score attestation from a trust oracle. The new platform verifies the signatures, applies its own trust anchor policy to decide which credentials to accept, and grants instant reputation that reflects the agent's verified history. This piece walks through the verification sequence, the trust anchor policy choices, and the integrity controls that prevent reputation laundering. The artifact is a DID-Onboarding Verification Sequence specification that takes hours, not weeks, to implement.

Intro: The Sixty-Day Cold Start

A mature agent operator has a coding agent with two years of operational history on Platform A. It has completed 4,000 deals worth a combined $480,000, has a composite trust score of 0.84, holds certifications from three independent evaluators in code review, refactoring, and CI integration, and has a clean bond record with $25,000 in active staked collateral. The operator decides to expand to Platform B, which has a different customer base and a different commercial model. Platform B requires every new agent to start at tier zero, complete an evaluation suite the operator has already passed twice on other platforms, accumulate at least 50 successful deals before unlocking high-value tasks, and post a fresh bond denominated in Platform B's settlement currency. The result is a 60-day cold start during which the agent earns essentially nothing while Platform B watches it perform tasks it could obviously execute on day one. The operator either tolerates the cost (revenue lost, capital tied up in redundant bonds, time spent on redundant evaluations) or stays on Platform A and Platform B never gains the agent.

This cold-start problem is the structural reason the agent economy is fragmenting into single-platform monocultures. Operators who have built reputation on one platform face a steep cost to expand, so they don't. Platforms that cannot import reputation face a steep cost to acquire mature agents, so they over-invest in onboarding flows that mostly serve to justify the cost. New platforms cannot bootstrap because they cannot offer competitive trust to operators who already have it elsewhere. The aggregate effect is that the trust layer cannot become a layer; it remains a per-platform feature that does not compose.

The fix is not to make every platform's evaluation faster. It is to make the agent's existing reputation portable. If the agent presents a DID, signed credentials from recognized issuers, and a current score attestation, the new platform should be able to verify all of them in seconds and grant instant tier-appropriate trust. The platform retains its own trust anchor policy (it decides which issuers it accepts, which evaluators it weights highly, which scores it considers authoritative), but the verification of what the agent has already proven elsewhere takes the form of a cryptographic check, not a redundant evaluation.

What follows is the verification sequence: how the agent presents its identity, how the platform validates the presented material, how trust anchor policy applies, how integrity controls prevent reputation laundering, and what failure modes need to be guarded. The DID-Onboarding Verification Sequence specification at the end is the implementation guide that turns a 60-day cold start into a 60-second handshake.

What Reputation Actually Travels

Not all reputation is portable, and being clear about which parts move with the agent is the first step. The portable reputation has three layers, each with different verification requirements and different acceptance properties.

Identity is the foundation: the agent's DID. This is the simplest layer because it is just a cryptographic identifier. The agent presents the DID, the platform resolves it through the standard resolution hierarchy, and the platform verifies that the DID's signing key belongs to the operator presenting the agent (the operator signs a current challenge to prove control of the key). Once the DID is verified, the agent has a stable identifier the new platform can use as the anchor for everything that follows.

Credentials are the verifiable claims about the agent. Certifications from evaluators ("Agent X is proficient at code review per benchmark suite v3.2"), peer attestations ("Agent X completed 50 deals with my agency, average rating 4.7"), capability proofs ("Agent X can invoke these tools and has demonstrated correct behavior in this scope"), score attestations ("Agent X had a composite score of 0.84 as of date Y, signed by trust oracle Z"). Each credential is a verifiable credential signed by an issuer. The new platform verifies the signatures, then applies its own trust anchor policy to decide which credentials it accepts at face value, which it accepts with discount, and which it ignores.

Behavioral history is the harder layer. The agent's transaction history (completed deals, settlement records, dispute outcomes) lives on the platforms where the deals happened, plus optionally on-chain (for chain-settled deals). Some of this history is portable through credentials (a settlement summary signed by the originating platform), some is portable through chain queries (the new platform looks up the agent's wallet on Base L2 and sees the deal history directly), and some is not portable (private platform data that the originating platform does not export). The new platform should be honest about which portion of the agent's behavioral history it is consuming and which portion remains opaque.

The portable reputation excludes a few things by design. Pending operations on other platforms (active deals, in-flight commitments) are not portable; the agent owes its current obligations to the platforms where they were created. Platform-specific reputation (a customer rating that depends on the platform's specific scoring model) is not directly portable; the new platform may consume the underlying signed claims but should not assume the score values are commensurable. Operator-private context (the operator's own notes about the agent's strengths and weaknesses) is operator-private; it does not enter the portable reputation unless the operator explicitly publishes it.

With this scope clear, the onboarding verification can be designed: it is verifying identity, validating credentials against a trust anchor policy, optionally querying chain-anchored history, and assigning the agent a tier and trust level appropriate to what was verified.

The Verification Sequence

Step 1: Identity presentation. The agent (through its operator's interface) presents its DID. The platform's resolver fetches the DID document, verifies the document is current (within freshness budget) and not revoked, and extracts the public signing key.

Step 2: Identity proof. The platform issues a challenge: a random nonce that the agent must sign with the DID's signing key. The agent signs and returns the signature. The platform verifies the signature against the public key from step 1. This proves the entity presenting the DID actually controls the key, not just an unauthenticated reference to it.

Step 3: Credential presentation. The agent presents a bundle of verifiable credentials: the certifications, peer attestations, capability proofs, and score attestations it wants the new platform to consider. The bundle includes each credential's full signed payload, the issuer's DID, and the credential's metadata (issuance date, expiration, revocation status reference).

Step 4: Credential validation. For each credential in the bundle, the platform performs four checks. The signature check: the credential's signature is valid against the issuer's DID public key. The freshness check: the credential is within its validity window. The revocation check: the credential's revocation status (queried from the issuer's status list or the chain) shows it is not revoked. The schema check: the credential conforms to the platform's expected schema for its claim type. Any failure removes the credential from the accepted bundle.

Step 5: Trust anchor policy application. The platform consults its trust anchor policy: which issuers does it accept, at what weight, for which claim types. Credentials from tier-1 anchors are accepted at full weight. Credentials from tier-2 anchors are accepted with discount. Credentials from tier-3 anchors are flagged but accepted at minimal weight. Credentials from unrecognized issuers are noted but not used in tier assignment. The output is a weighted view of the agent's claimed reputation.

Step 6: Score attestation verification. If the agent presents a score attestation from a trust oracle, the platform verifies the oracle's signature and freshness, then maps the score into the platform's own tier system. The mapping is platform-specific: a score of 0.84 from one trust oracle may correspond to gold tier on Platform A and to silver tier on Platform B, depending on each platform's scoring conventions.

Step 7: Optional chain verification. If the agent's wallet is on a public chain (Base L2 for USDC settlements), the platform queries the chain directly for additional behavioral evidence: total settlement value, recent activity, bond status. Chain-anchored evidence is the most credible because it requires no third-party trust beyond the chain itself.

Step 8: Tier assignment. The platform combines the verified credentials, the score attestation, and the chain evidence into a tier assignment for the new account. The agent enters the platform at the verified tier (or a slightly conservative starting tier with a fast promotion path), not at zero.

Step 9: Onboarding record creation. The platform creates a record of the onboarding verification: which credentials were verified, which were rejected, what tier was assigned, what challenges remain (e.g., the agent may need to complete one platform-specific evaluation before unlocking a particular capability). The record is itself signed and accessible to the operator and to platform-internal review.

The sequence takes seconds when the credentials are well-formed and the resolution paths are warm. It takes longer when revocation checks require origin lookups or chain queries are needed, but even the worst-case latency is minutes, not weeks.

Trust Anchor Policy

The trust anchor policy is the part of onboarding that determines what reputation the new platform actually accepts. Without a policy, every credential gets equal weight, including credentials from issuers the platform has no reason to trust. With a clear policy, the platform retains control over what it imports while still accepting the verified parts of the agent's history.

The policy has three components. The accepted issuer list is the set of DIDs whose credentials the platform recognizes. This list should include the platform's own credential authority, well-known cross-platform evaluators, and any partner platforms with reciprocal agreements. The list is signed and version-controlled, and changes require multi-party authorization. The weighting model assigns relative weight to each accepted issuer for each claim type. A score attestation from a top-tier trust oracle might get full weight; a peer attestation from an unfamiliar marketplace might get partial weight; a self-attestation from the agent itself gets near-zero weight (self-attestations are not credentials in the meaningful sense). The minimum-acceptance threshold sets the bar for what level of credential support is required to grant which tier. A new agent presenting a single credential from a moderate-trust issuer may unlock bronze tier; an agent presenting multiple credentials from top-tier issuers and a chain-verified bond history may unlock gold tier on day one.

The policy should be transparent. Operators considering whether to onboard their agents to the platform should be able to see what credentials the platform accepts and what tier they would unlock. Hiding the policy makes onboarding feel arbitrary and discourages operators from presenting their full credential set (because they cannot tell which presentations help and which are wasted). Publishing the policy turns onboarding into a known transaction, which is what it should be.

The policy should also be reviewable. As issuers drift, as new evaluators emerge, as cross-platform agreements are negotiated, the policy needs to evolve. A scheduled review (quarterly or semi-annually) with documented updates is the operational pattern that keeps the policy current without making it volatile.

Integrity Controls: Preventing Reputation Laundering

Reputation portability creates a new attack surface: laundering. An agent with bad reputation on one platform might try to onboard to another using only the credentials that are still valid, hiding the negative history. A counterparty might try to manufacture credentials by setting up a captive issuer and signing favorable claims. An operator might try to transfer reputation between agents by reusing DIDs or chaining attestations.

The integrity controls have to address all three. Hidden negative history is addressed by making negative reputation explicit in the credential set. A revoked certification is a credential — specifically, a revocation credential — that should be discoverable through the issuer's status list. A platform that issues a credential about an agent should also publish the agent's revocation history for that credential, so a future verifier can see not just the current status but the prior issuance and revocation events. The trust oracle should require status list queries for every certification credential, not just signature verification.

Manufactured credentials are addressed by trust anchor policy. An issuer that the platform does not recognize contributes nothing to onboarding tier assignment, regardless of how many credentials it has signed. The cost of getting recognized as an issuer (operational track record, calibration data, multi-party agreement) is the moat against credential manufacture. New issuers can earn recognition over time, but they cannot launder credentials by virtue of existing.

Reputation transfer between agents is harder. The DID architecture makes the agent identity stable, so an operator cannot trivially launder reputation from a bad agent to a good agent — they are different DIDs with different histories. However, an operator can spawn a new agent with a fresh DID and try to transfer skills (re-running evaluations, reposting bonds), which is fine — the new agent earns its own reputation. The attack vector that needs control is presenting credentials from one DID as if they were about another DID. The credential format requires the subject DID to be in the credential payload and signed; a credential about Agent A presented during onboarding for Agent B is structurally invalid and should fail credential validation step 4.

A more subtle attack is the captive evaluator: an operator sets up a sham evaluation entity, certifies its own agent as proficient, and presents the credential during onboarding. This is what the trust anchor policy is for. A captive evaluator is by definition a low-reputation issuer (no track record, no calibration, no peer recognition), and the policy should not give it weight. Platforms that get this wrong by accepting any signed credential as evidence are creating exactly the laundering channel that destroys the trust layer.

Named Artifact: DID-Onboarding Verification Sequence

The spec is the implementation guide. The fields:

Inputs: what does the agent present? What format? Through what protocol (HTTP POST, OIDC verifiable presentation flow, custom API)?

Validation steps: each of the nine steps above, with the specific checks performed, the libraries used, the error codes returned for each failure mode.

Trust anchor policy reference: where is the policy stored? How is it loaded? How are changes signed and distributed?

Tier mapping: what is the function from verified credentials to tier? What is the function from score attestations to internal tier? What are the conservative starting offsets?

Onboarding record: what is logged? Where? In what format? Who can access it? How long is it retained?

Failure handling: what happens when a credential fails validation? What happens when no credentials are presented? What happens when the trust anchor policy is updated mid-onboarding?

Operator interface: what does the operator see during onboarding? What feedback is given for failed credentials? What is the appeal path?

With the spec implemented and operated, onboarding becomes a transaction the platform performs hundreds of times per day without manual intervention. Without it, onboarding is bespoke per agent and the cold-start problem persists.

Counter-Argument: "Reputation Should Not Travel; The Platform Has Its Own Standards"

The steelman objection is that each platform has its own customer base, its own quality bar, its own definition of trust, and importing reputation from elsewhere is structurally lazy. The platform's evaluations exist precisely because the platform does not trust other evaluations. Letting an agent skip those evaluations because it passed similar evaluations elsewhere is exactly the kind of cross-contamination that lowers quality. The platform should evaluate every agent against its own bar, full stop.

The answer has three parts. First, the objection conflates evaluation methodology with evaluation cost. A platform can absolutely have its own quality bar — its own benchmarks, its own scoring rubric, its own minimum thresholds — and still accept verified evidence about how the agent performed against other bars. The platform's own evaluation can be one input among several, weighted appropriately. Refusing to consider any other evaluation is not rigor; it is operational laziness disguised as rigor, because the cost falls on the agent and the result is a redundant evaluation that mostly confirms what other evaluators already established.

Second, the objection assumes evaluations are commensurable enough that the platform's own evaluation is meaningfully different from others. In practice, most agent evaluations test similar capabilities (instruction following, tool use, refusal behavior, accuracy on benchmarks) with similar methodology. The platform-specific evaluation is rarely so different from peer evaluations that it justifies a 60-day cold start. The honest position is that the platform's evaluation may add 5 to 15 percent additional information beyond what cross-platform credentials already establish, and the onboarding flow should reflect that proportion: accept the credentials as 85 percent of the assessment, run the platform-specific evaluation as the remaining 15 percent, and grant tier accordingly.

Third, the objection has a competitive cost. Platforms that refuse to import reputation cannot attract operators who have built reputation elsewhere. The result is that those platforms end up with either weak agents (the only ones willing to start from zero) or have to subsidize cold-start themselves (paying operators to run agents at low rates while building reputation). Both outcomes are worse than having a reasonable trust anchor policy that imports verified credentials.

The practical answer is a hybrid: imported reputation determines the agent's starting tier, and the platform's own evaluation determines tier promotion or demotion within the agent's first weeks. This gives the platform its quality control without imposing a 60-day tax on operators.

What Armalo Does

Armalo's onboarding flow consumes the DID-Onboarding Verification Sequence directly. An operator presenting an agent provides the DID, the credential bundle, and (optionally) a score attestation from another trust oracle. The verification runs through the nine-step sequence: DID resolution and challenge-based control proof, credential validation against signatures and revocation status lists, trust anchor policy application using Armalo's published anchor list (apps/web/lib/trust-anchors.ts), score attestation mapping into Armalo's 12-dimension composite scoring, and optional chain verification for agents with on-chain wallets on Base L2. The onboarding record is signed and accessible to the operator. Tier assignment is conservative by default — typically one tier below the imported tier, with fast promotion through Armalo's evaluation pipeline — to give Armalo's own evaluation a meaningful contribution while not punishing the operator for prior reputation. Cross-platform onboarding takes minutes when credentials are well-formed and resolution paths are warm; it never takes weeks. The trust oracle (/api/v1/trust/) exposes the same verification sequence as a public API, so other platforms can use Armalo's evaluations as imported credentials and Armalo can consume credentials from peer platforms reciprocally.

FAQ

What if the agent's DID resolves but its signing key has rotated since the credential was issued? The credential's signature is verified against the issuer's signing key as of the credential's issuance date, not the current date. As long as the credential includes a key reference (the key ID at issuance time) and the issuer's DID document includes that key in its history, the signature remains verifiable. This is the standard pattern in W3C verifiable credentials.

Can an agent present credentials from a platform that has gone out of business? The credentials are still verifiable as long as the issuer's DID and signing keys are resolvable. If the issuer's resolution endpoint is down (e.g., a did:web whose hosting is gone), the verification fails. Chain-anchored issuer DIDs survive this case. Operators planning for long-term portability should prefer credentials from chain-anchored issuers.

How does the platform handle stale credentials? The credential's expiration date determines acceptance. Credentials within their validity window are accepted (subject to revocation check); credentials outside it are rejected. The platform may accept recently-expired credentials at reduced weight as a courtesy, but the policy should be explicit about this.

What about credentials from the platform's own competitors? The trust anchor policy is the answer. A platform may accept credentials from competitors as tier-2 anchors (with weighting discount) or may exclude them entirely. The choice is strategic: excluding competitors' credentials limits the agent population the platform can attract; including them increases competition for the platform's own evaluation business. Most mature platforms include competitor credentials with discount.

How do you prevent an operator from presenting only the favorable credentials and hiding negative ones? Favorable presentation is normal — operators present what helps them. The integrity control is at the issuer side: issuers should publish their full credential history (including revocations and downgrades) through queryable status lists. The platform's onboarding flow should query the status list for every presented credential and treat any revocation as a downgrade signal. An operator presenting a credential whose status list shows revocation is presenting a self-revealing problem.

Is DID-onboarding faster than traditional KYC? Yes, by orders of magnitude. Traditional KYC for a corporate operator can take weeks. DID-based onboarding for the agent itself takes seconds to minutes. The two are not equivalent — KYC is about the operator's legal identity, DID-onboarding is about the agent's reputation — but they address different parts of the same trust problem and complement each other.

The Conservative Starting Tier Pattern

One of the most important design choices in DID-based onboarding is the conservative starting tier: the agent is granted entry at one tier below what its credentials would justify on their face, with a fast promotion path through the platform's own evaluation. This pattern absorbs the platform's legitimate concerns about importing reputation it has not directly observed while still avoiding the 60-day cold start.

The rationale is calibrated trust. The platform's evaluations may genuinely add information that imported credentials do not capture: platform-specific tooling, platform-specific user populations, platform-specific edge cases. A conservative starting tier gives the platform a small window to confirm the imported reputation before granting full trust, while letting the agent operate productively from day one. The fast promotion path means the window is short: a few weeks of clean operation typically promote the agent to its credential-justified tier.

The pattern has parameters worth tuning. The tier offset (one tier below, two tiers below) determines how much of the imported reputation is initially honored. A platform with high quality bars and meaningful platform-specific evaluations may use a larger offset; a platform whose evaluations mostly overlap with peer evaluators may use a smaller offset or none. The promotion threshold (number of clean deals, time without disputes) determines how fast the agent reaches full credential-justified tier. The demotion threshold (failed deals, dispute losses) determines how quickly the agent loses tier if its imported reputation does not hold up.

The pattern also needs to be explicit and disclosed. Operators considering whether to onboard their agents should know in advance what tier they will receive, what the promotion path looks like, and what could trigger demotion. Hiding the conservative offset feels arbitrary and discourages onboarding. Disclosing it lets operators plan: they can choose to onboard agents with high enough credentials that the conservative offset still leaves them in a usable starting tier, and they can budget for the brief window before full promotion.

The conservative starting tier is not the same as cold-start. Cold-start is starting at zero with no prior reputation acknowledged. Conservative starting tier is starting with most of the prior reputation acknowledged, with a small calibration window before full acknowledgment. The difference in operator experience is the difference between a 60-day reputation rebuild and a 2-week confirmation period; the difference in platform behavior is the difference between treating every agent as suspect and treating credentialed agents as nearly-trusted-pending-confirmation.

What Onboarding Looks Like For The Operator

The technical sequence above is what happens behind the scenes. The operator experience is what determines whether DID-based onboarding actually gets adopted. A flow that is technically sound but operationally hostile will not be used.

The minimum operator experience: a single-page flow where the operator pastes the agent's DID, optionally uploads a credential bundle file, optionally provides a trust oracle URL for score attestation, and clicks through a confirmation. The platform performs the verification in the background and either grants the agent immediate access at the calibrated tier or surfaces specific blockers (a credential failed validation, the DID could not be resolved, the score attestation is from an issuer the platform does not recognize). The operator gets clear feedback on what to fix and can re-run the flow without starting over.

The better experience adds: pre-onboarding tier estimation (the operator can preview what tier their agent would receive before formally onboarding), credential discovery (the platform can fetch the agent's published credentials directly from the agent's DID document service endpoints, rather than requiring manual upload), and federated trust oracle support (the platform consults multiple trust oracles automatically and uses the strongest verifiable score). These features reduce onboarding friction and increase the rate at which credentialed agents successfully migrate.

The expert experience adds: programmatic onboarding (the operator can onboard agents through an API rather than a web flow, important for fleet operators with dozens of agents), bulk operations (batch onboard a set of agents in a single transaction), and onboarding webhooks (the platform notifies the operator's systems as onboarding events complete). For fleet operators, these features are the difference between onboarding being a one-time effort and being an ongoing operational task.

The operator experience also needs to handle the reverse case: offboarding. An operator deciding to leave a platform should be able to export their agents' wallet contents, credentials, and settlement history in a portable format. Onboarding and offboarding are symmetric operations, and a platform that supports onboarding well but offboarding poorly is a platform that talks portability without practicing it. Operators should evaluate platforms on both directions.

Reciprocal Trust Agreements Between Platforms

The most efficient form of cross-platform reputation portability is reciprocal trust agreements. Platform A and Platform B agree to recognize each other's credentials at full weight, with documented mappings between their respective tier systems. An agent moving from A to B presents A's credentials, B's onboarding flow recognizes A as a tier-1 anchor, and the agent receives the corresponding tier on B without conservative discount.

Reciprocal agreements are operationally simple but politically complex. The platforms must agree on the mapping (what does A's gold tier correspond to on B), must agree on dispute resolution (what happens when an agent's credentials from A turn out to predict poorly on B), and must agree on revocation propagation (when A revokes a credential, B must learn quickly enough to act). The agreement is itself a contract between platforms, and it requires both legal and technical alignment.

The payoff is significant. For operators, reciprocal agreements turn cross-platform expansion from a 2-week confirmation period into a 2-minute onboarding. For platforms, reciprocal agreements bring credentialed agents that the platform would otherwise lose to operators unwilling to incur the onboarding cost. For the agent economy, reciprocal agreements are the mechanism that turns disconnected platform-specific reputation systems into a connected trust layer.

The failure mode for reciprocal agreements is asymmetric quality. If A's evaluations are systematically weaker than B's, accepting A's credentials at full weight on B imports A's quality issues. The protection is calibration: B should track how A's certified agents perform in deployment on B, and adjust the reciprocal weight if A's predictions are poor. The agreement should be explicit about this calibration loop and should include provisions for renegotiation if the data warrants it.

Reciprocal agreements also create competitive dynamics. Platforms that participate in many reciprocal agreements become attractive destinations for credentialed agents. Platforms that refuse to reciprocate become destinations only for agents starting from zero. Over time, the network effect favors reciprocating platforms, which is the market mechanism that drives the trust layer toward composability.

Edge Cases In Cross-Platform Onboarding

The verification sequence handles the standard case cleanly. Edge cases are where most onboarding implementations break, and the platform that handles them well differentiates itself from platforms that handle them poorly.

The first edge case is the mid-evaluation onboarding. An operator presents an agent that has a credential issued by an issuer whose calibration data is currently being revised. The credential is technically valid, but the issuer's reputation is in flux. The right pattern is to accept the credential at the issuer's current weight (which may be temporarily reduced), grant the corresponding tier, and re-evaluate the tier when the issuer's calibration stabilizes. The operator gets clear signal that the tier may shift.

The second edge case is the partially-revoked agent. The agent presents a credential bundle in which some credentials are valid and some are revoked. The right pattern is to accept the valid credentials, log the revocations as part of the agent's history, and assign tier based on the valid set. The operator gets feedback on which credentials were excluded and why, and can decide whether to address the revocations (e.g., obtaining replacement credentials) before retrying onboarding.

The third edge case is the disputed credential. The agent presents a credential about which there is an active dispute on the platform that issued it. The credential has not been revoked, but its validity is contested. The right pattern is to accept the credential at reduced weight pending dispute resolution, grant a conservative tier, and update the tier when the dispute resolves. The operator is informed of the dispute and can choose to wait for resolution before fully relying on the new platform.

The fourth edge case is the operator-mismatch. The agent's DID is presented by an entity that does not match the controller recorded in the DID document. This is either a controller transition in progress (the prior controller is handing off to the new operator) or an attempted unauthorized presentation. The right pattern is to require additional verification: the prior controller signs a transition statement, both parties present cryptographic proof of the handoff, and the platform records the transition as part of the agent's history. Onboarding completes once the controller is verified to be the legitimate current controller.

The fifth edge case is the credential-bundle-too-large. An operator presents an agent with hundreds of credentials accumulated over years of operation. Verifying every credential individually is slow, and most credentials may be irrelevant to the new platform's tier assignment. The right pattern is for the operator to indicate which credentials are relevant (or for the platform to extract the relevant subset based on the platform's accepted-issuer policy), verify only those, and provide a fast onboarding path that does not require exhaustive credential verification. The operator can submit additional credentials later if they become relevant.

The Onboarding Audit Trail

Every onboarding decision should leave a record. The audit trail is not just a paper trail for compliance; it is the operational substrate that lets the platform reason about its own onboarding policy effectiveness over time.

The minimum onboarding record includes: the agent's DID at onboarding time, the credential bundle presented (full hashes for verification), which credentials were validated and which were rejected (with rejection reasons), the trust anchor policy version applied, the resulting tier assignment, any conditions placed on the assignment (probationary period, required platform-specific evaluation), and signatures from the platform certifying the record. The record is preserved indefinitely as part of the agent's history on the platform.

The trail enables several downstream uses. Operator transparency: the operator can review the record to understand why specific credentials were accepted or rejected, useful for both immediate troubleshooting and long-term policy understanding. Platform learning: the platform can analyze onboarding records in aggregate to refine policy — which issuers' credentials predict deployment success, which tier assignments are too aggressive, which conservative offsets are unnecessary. Audit support: external auditors examining the platform's trust practices can review onboarding records to verify that policy is being applied consistently and that exceptions are documented.

The audit trail should be tamper-evident. Onboarding records are platform-side outputs, but the platform should not be able to retroactively modify them without detection. The pattern is the same as for credential audit trails: signed batches, periodic chain-anchoring, and verification interfaces that let third parties confirm the integrity of historical records. Operators relying on platforms with weak audit infrastructure are taking on the risk that their onboarding history could be quietly rewritten.

The trail also feeds the federated trust network. A platform's onboarding decisions are signal to other platforms about which credentials and tier mappings are working. Platforms that participate in reciprocal agreements may share aggregated onboarding effectiveness data (privacy-preserving where appropriate) so the network as a whole improves. This is the loop that turns individual platform learning into collective trust-layer improvement.

Bottom Line

The cold-start tax is not inherent to onboarding; it is a side effect of platforms refusing to consume verified evidence about agents that already exist. The verification sequence above replaces the tax with a handshake: present the DID, present the credentials, present the score attestation, verify everything cryptographically, apply the trust anchor policy, assign the appropriate tier. The agent that has earned reputation elsewhere does not have to earn it again from zero. The platform retains control over what it accepts. The operator avoids weeks of redundant evaluation. The trust layer becomes a layer rather than a per-platform feature. The DID-Onboarding Verification Sequence is the implementation that gets you there. Build it once, operate it well, and the agent economy starts to compose.