Kinetic Trust Protocol (KTP) - Vector Identity Specification

This document specifies the Vector Identity system for the Kinetic Trust Protocol (KTP). Vector Identity replaces static credentials with trajectory-based authentication, where identity is proven through continuous movement rather than possession of secrets.

The specification covers Trajectory Chains (cryptographically linked transaction histories), Proof of Resilience (attestations of survival under stress), Sponsorship Bonds (trust staking for new agents), and Lineage Evolution (the maturation path from dependent to autonomous).

Introduction

Traditional identity systems treat identity as a static property - an entity either possesses the correct credential or it does not. This binary model fails catastrophically when credentials are stolen, forged, or replayed, because there is no mechanism to distinguish the legitimate holder from an impersonator.

Vector Identity addresses this by treating identity as a trajectory rather than a position - a continuous line of movement through state space rather than a single point of authentication.

Trajectory-based standing, Proof of Resilience, sponsorship accounting, and lineage in this document apply to software agents. They MUST NOT become human behavioral dossiers, personal scores, or prerequisites for a person's access to explanation, correction, or review. Human identity assurance and operation-specific eligibility follow [KTP-HUMAN] and specifications/human-eligibility.md; an actual software executor retains its own identity, capacity, and readiness requirements.

The Passport Fallacy

Current systems commit the "Passport Fallacy": they assume that possession of a credential (passport, API key, certificate) proves identity. This assumption is false because:

1. Credentials can be stolen: An attacker who obtains an API key can present it just as effectively as the legitimate holder.

2. Credentials carry no history: A stolen key at T=100 looks identical to a legitimate key at T=100. There is no record of how the presenter obtained the key or what they did before.

3. Credentials are static: Once issued, a credential's "identity" never changes, even if the presenting entity's behavior becomes anomalous or malicious.

In the age of autonomous agents operating at machine speed, these flaws become catastrophic. An attacker who compromises one API key can spawn thousands of malicious agents in milliseconds, each presenting valid credentials.

Identity as Trajectory

Vector Identity replaces the static credential model with a trajectory-based model where identity is proven by continuous movement rather than possession of secrets.

Key insight: A trajectory cannot be stolen because it includes not just current position, but also:

• Where the entity came from (previous state)
• How fast it's moving (velocity)
• What resistance it encountered (friction)
• Who witnessed the movement (attestations)

An attacker can steal a credential (a point), but they cannot steal a trajectory (a line) because the line includes historical relationships that the attacker cannot retroactively forge.

For software operations, the comparison is between:

• A credential presented without evidence of the expected executing artifact or current state
• An authenticated software identity bound to the expected artifact, verified committed history, and current operation-specific readiness

These are distinct verification requirements. Historical records alone do not authenticate the current executor or prove its readiness; the live bindings and checks in the trajectory and readiness companions remain necessary. This comparison does not prescribe tracking a human's travel, activity, or tenure.

Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Terminology

This section defines terms specific to Vector Identity. Terms defined in [KTP-CORE] apply here as well.

Ancestral Authority: Trust inherited from predecessors in a Lineage. Agents descended from proven Guarantor Lineages inherit a portion of ancestral credibility.

Ancestral Liability: The permanent, depth-decaying share of responsibility a sponsor retains for the descendants it vouched for, after the Sponsorship Bond has closed. The dual of Ancestral Authority: credit and liability travel the same lineage, at the same decay, without end.

Attestation of Passage: A signed statement by a Trust Oracle confirming that an agent successfully completed a transaction at a specific time and environmental state.

Chain Link: A single transaction record in a Trajectory Chain, containing state, signatures, and hash of the previous link.

Continuity Violation: An impossible state transition, such as an agent appearing in two locations simultaneously or moving faster than physically possible. Indicates forgery or compromise.

Friction: Environmental resistance encountered during a transaction, derived from the Risk Factor (R). High friction indicates stressful conditions; success under high friction is worth more for Proof of Resilience.

Genesis Transaction: The first transaction in an agent's Trajectory Chain, created when the agent is spawned. Requires a Sponsorship Bond.

Laminar Flow: Smooth, consistent agent behavior with predictable velocity and trajectory. Indicates legitimate operation.

Lineage: The evolutionary history and current maturation phase of an agent. Lineages progress from Sponsored through Independent to Guarantor.

Proof of Resilience: A ledger of attestations demonstrating an agent's successful transactions, weighted by the friction encountered. Forms the primary input to E_base calculation.

Sponsorship Bond: A cryptographic commitment where a high-mass entity stakes a portion of its trust on behalf of a new agent. The sponsor is penalized if the sponsored agent misbehaves.

Trajectory Chain: A cryptographically linked sequence of transaction records that forms an agent's verifiable history.

Turbulent Flow: Erratic, inconsistent agent behavior with unpredictable velocity and trajectory. Indicates potential compromise or malicious operation.

Velocity: The rate at which an agent moves through state space, measured in transactions per unit time. Sudden velocity changes may indicate anomalous behavior.

Vector Identity Model

Identity as Verb

Traditional identity answers "Who is this?" - a noun question. Vector Identity answers "What has this been doing?" - a verb question.

The fundamental shift:

+------------------+------------------------+
| Static Model     | Vector Model           |
+------------------+------------------------+
| Passport         | Trajectory             |
| Credential       | Chain                  |
| Point            | Line                   |
| Possession       | Movement               |
| Who you are      | What you've been doing |
| Noun             | Verb                   |
+------------------+------------------------+

In the Vector Model, an entity's identity IS its trajectory. An agent that has been operating legitimately for 10,000 transactions has a fundamentally different identity than an agent that appeared from nowhere, even if both present identical API keys.

Position and Momentum

Vector Identity has two components:

Position (current state): Where the agent is right now - its current Trust Score, active permissions, and environmental context. This is roughly equivalent to what a static credential provides.

Momentum (historical trajectory): Where the agent has been - its complete transaction history, attested by Trust Oracles, forming a cryptographic chain. This is what static credentials lack entirely.

The combination of position and momentum forms a "vector" in identity space, just as a physical vector combines position and direction.

Momentum carries inertia: an agent with deep history is "heavier" and harder to deflect from its trajectory. This heaviness manifests as:

• Higher E_base (more base trust)
• More resistance to false accusations
• Greater ability to sponsor new agents
• Preferential treatment during network stress

Laminar vs. Turbulent Flow

Agents can be characterized by their flow pattern:

Laminar Flow (legitimate):

• Consistent velocity (transactions per second stays stable)
• Predictable trajectory (actions follow logical patterns)
• Normal friction response (slows down when R increases)
• Continuous presence (no unexplained gaps or teleportation)

Turbulent Flow (suspicious):

• Erratic velocity (sudden bursts or stops)
• Chaotic trajectory (unrelated actions, no logical sequence)
• Abnormal friction response (ignores environmental stress)
• Discontinuous presence (gaps, simultaneous appearances)

Implementations SHOULD monitor agent flow patterns and flag transitions from laminar to turbulent as potential compromise indicators.

The Trust Oracle MAY reduce an agent's E_base if sustained turbulent flow is detected, even if individual transactions succeed.

Trajectory Chains

The Trajectory Chain is the core data structure of Vector Identity. It is a cryptographically linked sequence of transaction records whose integrity depends on complete signature bindings, verified continuity, and an independently authenticated final head. The normative v3 signing, hashing, anchoring, and migration contract is specifications/trajectory-signatures.md.

Chain Structure

A Trajectory Chain consists of a Genesis Transaction followed by zero or more Transaction Records, each linked to its predecessor by cryptographic hash.

+-------------------+
| Genesis           |
| Transaction       |
| (sponsored)       |
+--------+----------+
         |
         | hash
         v
+-------------------+
| Transaction       |
| Record 1          |
+--------+----------+
         |
         | hash
         v
+-------------------+
| Transaction       |
| Record 2          |
+--------+----------+
         |
         | hash
         v
         .
         .
         .
         |
         | hash
         v
+-------------------+
| Transaction       |
| Record N          |
| (current)         |
+-------------------+

Figure 1: Trajectory Chain Structure

The chain is append-only. Records MUST NOT be modified or deleted once added.

Transaction Records

Each active Transaction Record MUST satisfy the v3 schema at schemas/transaction-record.json and declare record_version = "ktp-trajectory-v3". Its fields include:

+--------------------+----------+-----------------------------------+
| Field              | Type     | Description                       |
+--------------------+----------+-----------------------------------+
| record_id          | string   | Unique identifier for this record |
| chain_id           | string   | Agent's chain identifier          |
| sequence           | integer  | Position in chain (0 = genesis)   |
| timestamp          | datetime | When transaction occurred         |
| previous_hash      | string   | Final hash of previous record     |
| previous_state     | object   | Agent state before transaction    |
| current_state      | object   | Agent state after transaction     |
| action             | object   | What action was performed         |
| friction           | number   | Environmental R at time of action |
| velocity           | number   | Agent's transaction rate          |
| agent_signature    | string   | Agent-role compact JWS            |
| oracle_attestation | object   | Trust Oracle's attestation        |
| record_hash        | string   | Hash of final signed envelope     |
+--------------------+----------+-----------------------------------+

The v3 record additionally requires record_version, agent_id, zone_id, conformance_level, evaluation_profile_digest, and migration_checkpoint. The migration_checkpoint is null for an ordinary record; an authorized legacy-to-v3 genesis carries the approved checkpoint digest. The schema fixes the permitted fields and requires all body fields; action.details remains extensible JSON whose complete contents are signed. Implementations MUST reject unknown structural fields, missing required fields, duplicate JSON member names, invalid Unicode, and data outside the canonicalization and numeric limits in specifications/trajectory-signatures.md. A candidate's version, level, profile digest, or key identifier MUST NOT choose a less restrictive verification policy.

The previous_state and current_state objects contain:

+------------+---------+----------------------------------+
| Field      | Type    | Description                      |
+------------+---------+----------------------------------+
| e_base     | number  | Base Trust at state              |
| e_trust    | number  | Effective Trust at state         |
| location   | string  | Logical location (zone, service) |
| tier       | string  | Trust Tier at state              |
| lineage    | string  | Lineage phase at state           |
| generation | integer | Generation number at state       |
+------------+---------+----------------------------------+

The action object contains:

+-------------+--------+--------------------------+
| Field       | Type   | Description              |
+-------------+--------+--------------------------+
| action_type | string | Category of action       |
| action_risk | number | Risk score (A) of action |
| target      | string | What the action targeted |
| result      | string | "success" or "denied"    |
| details     | object | Action-specific metadata |
+-------------+--------+--------------------------+

The oracle_attestation object contains:

+------------------+----------+--------------------------------+
| Field            | Type     | Description                    |
+------------------+----------+--------------------------------+
| oracle_id        | string   | Trust Oracle identifier        |
| attestation_time | datetime | When Oracle attested           |
| risk_factors     | object   | Environmental state at time    |
| oracle_signature | string   | Oracle's signature over record |
+------------------+----------+--------------------------------+

Co-Signature Requirements

Every active Transaction Record MUST carry both role-bound compact JWS signatures defined by specifications/trajectory-signatures.md. The signatures authenticate the complete record body and the Oracle's attestation without circular preimages. They do not alone prove that an action was permitted, that its stated outcome occurred, or that this envelope is the selected chain head; the Oracle MUST validate those claims and the required anchor evidence separately.

Define B as the entire top-level record excluding only agent_signature, oracle_attestation, and record_hash. B therefore includes both complete states, the entire action including details, identity and zone, chain and sequence, timestamp and predecessor, friction and velocity, record version, conformance level, evaluation profile digest, and migration checkpoint. Define O as the complete oracle_attestation object excluding only oracle_signature; it includes oracle_id, attestation_time, and all risk_factors.

The canonical payloads are:

agent_payload  = JCS(B)
oracle_payload = JCS({
  "record_body": B,
  "agent_signature": exact_agent_compact_JWS,
  "attestation": O
})

JCS means RFC 8785 canonical JSON encoded as UTF-8. The agent compact JWS MUST embed exactly agent_payload and protect exactly alg, kid, and typ, with typ = "ktp-trajectory-agent-v3". The Oracle compact JWS MUST embed exactly oracle_payload and protect exactly alg, kid, and typ, with typ = "ktp-trajectory-oracle-v3". Each protected header MUST also use JCS bytes. Verification MUST check the standard JWS signing input, the exact payload bytes, and the protected role, algorithm, and key against independently trusted configuration. Replacing the agent JWS with another envelope, even for the same body, changes the Oracle payload and requires a new Oracle signature. Detached payloads, unsigned algorithm declarations, and candidate-selected legacy fallback MUST NOT substitute for this contract.

Issuance proceeds as follows:

1. Validate the trusted format/profile, v3 structure, agent identity, and continuity; construct B and obtain the agent JWS over JCS(B).
2. Verify that exact agent JWS, the proposed action and state transition, and the environmental evaluation; construct O and oracle_payload.
3. In a consensus deployment, obtain the required commit evidence for the typed trajectory-intent digest of oracle_payload before Oracle signing. This intent excludes the Oracle signature and final record_hash, avoiding a circular dependency.
4. Produce and verify the Oracle JWS; calculate the final record_hash over JCS of the completed record excluding only record_hash. Use SHA-256 at Levels 1 and 2 or SHA-384 at Level 3, as selected by trusted configuration, and encode the lowercase hexadecimal digest with its sha256: or sha384: prefix.
5. Establish the independently authenticated final-head anchor required by the companion. In a mesh, reviewed agreement under specifications/oracle-consensus.md MUST bind record_version, the exact final record_hash, commit_intent, agent, zone, chain, sequence, and predecessor before the record is exposed or appended as authoritative standing. Persist that selection before acknowledging authority.

The final hash includes both exact JWS strings and the complete Oracle attestation. A commit to an intent is not a commit to this final envelope: independently valid ECDSA signatures can produce different envelope hashes for one intent. Only the uniquely anchored final hash may become the authoritative successor. Neither a recomputed unanchored hash nor a valid pair of signatures selects the head. Single-Oracle deployments still require the companion's independently trusted durable head selection and MUST NOT claim Byzantine agreement.

If either signature, continuity, evaluation, intent evidence, or final-head anchor is invalid or unavailable, the Oracle MUST NOT expose the candidate as authoritative. Existing Silent Veto and other authorization constraints remain binding.

Legacy History and Version Cutover

The former selective preimages omitted, among other fields, current_state, previous_state, chain_id, sequence, friction, velocity, and the Oracle identity and attestation time. Signature validity under those formulas does not authenticate those omitted claims. Changing an unanchored tail's state and recomputing its hash may leave the old formula signatures valid; an independently trusted commitment to the complete final record can detect the change. This describes the old specification's binding limitation, not evidence of a deployed exploit.

Legacy v2 records and their original bytes MUST remain historical evidence under schemas/transaction-record-legacy-v2.json. Implementations MUST NOT rewrite, silently reserialize, or automatically re-sign them as v3 history. An independently signed migration checkpoint from the already trusted authority MUST bind the legacy head and archive, independently revalidated carried state, and the authorized target chain, genesis, and evaluation profile before the new genesis is signed. It cannot retroactively authenticate facts omitted from legacy signatures.

The authorized new genesis body carries the checkpoint digest. Its final signed-envelope hash is anchored afterward; the checkpoint MUST NOT depend on that final hash. Cutover MUST durably enforce the v3 format floor and single-use lineage succession, including after restart, restore, or failover. A legacy archive verifier or a candidate-supplied version MUST NOT reopen legacy authority or create a second successor chain. Membership changes during migration additionally require the joint-transition evidence in specifications/oracle-consensus.md.

Continuity Enforcement

Trajectory Chains enforce physical continuity. An agent cannot "teleport" - appear at one location at time T and a distant location at time T+1 without traversing the intervening space.

Continuity rules:

1. Sequential numbering: Each record's sequence number MUST be exactly one greater than its predecessor.

2. Hash linking: Each record's previous_hash MUST exactly match the record_hash of its predecessor.

3. Temporal ordering: Each record's timestamp MUST be greater than its predecessor's timestamp.

4. State consistency: Each record's previous_state MUST match its predecessor's current_state.

5. Velocity bounds: The distance traveled (state change) divided by time elapsed MUST be within configured velocity limits.

Velocity bounds example:

If an agent's maximum velocity is 100 actions per second, and the previous record was at T=1000 with action_count=5000, then a record at T=1001 cannot have action_count greater than 5100.

Location-based continuity:

If zones are logically distant (require traversal through intermediate zones), an agent cannot appear in Zone B at T=1001 if it was in Zone A at T=1000 and the minimum traversal time from A to B is 10 seconds.

Continuity violations:

If a record fails any continuity check, the Trust Oracle MUST:

1. Reject the transaction
2. Flag the agent for investigation
3. Log the violation to the Flight Recorder
4. Optionally freeze the agent's Trust Score

Continuity violations strongly indicate either agent compromise (attacker does not have previous records) or Oracle compromise (attacker attempting to forge records).

Chain Verification

Any party with access to a Trajectory Chain can verify its integrity by checking:

1. Genesis validity: The genesis transaction is properly sponsored and signed by a valid sponsor.

2. Chain integrity: For each record N (N > 0): - previous_hash(N) == record_hash(N-1) - sequence(N) == sequence(N-1) + 1 - timestamp(N) > timestamp(N-1) - previous_state(N) == current_state(N-1)

3. Signature and hash validity: For each active record, validate the v3 schema, RFC 8785 payload bytes, role-bound agent and Oracle JWS, and final completed-envelope hash under specifications/trajectory-signatures.md. Obtain allowed versions, algorithms, keys, and profile from trusted configuration rather than the candidate.

4. Head and cutover validity: Verify the independently authenticated final-head anchor and its record_version, exact record_hash, commit_intent, identity, zone, chain, sequence, and predecessor binding. Verify any migration checkpoint and the durable single-use succession and format floor. A candidate-supplied head or a self-consistent unanchored suffix is insufficient.

5. Continuity: For each adjacent pair of records: - Velocity is within bounds - Location transitions are physically possible

Verification can be performed:

• Fully: Check every record from genesis to current (expensive but complete)

• Sampled: Check random subset of records (faster but probabilistic)

• Windowed: Check only recent N records (fastest but only validates recent history)

Trust Oracles SHOULD perform full verification periodically. PEPs MAY perform windowed verification for real-time decisions.

Sampled or windowed checks MUST NOT bypass verification of the candidate's complete v3 signature bindings, final hash, independently authenticated head, or migration/format floor. A window MUST start from an independently trusted checkpoint with verified continuity; sampling alone does not establish authority for an unanchored tail.

Proof of Resilience

Proof of Resilience is a ledger of attestations demonstrating an agent's successful operation under stress. It is the primary input to E_base calculation.

Historical PoR MUST NOT be automatically reduced for elapsed time or inactivity. The evaluated ledger may change when authenticated evidence establishes that a claim was invalid, but the correction MUST be appended with its authority and provenance; the original signed history MUST NOT be silently rewritten. Expiry or revocation of a current external instrument remains governed by that instrument's existing rules.

Attestation Structure

Each Proof of Resilience attestation contains:

+-------------------+----------+---------------------------------+
| Field             | Type     | Description                     |
+-------------------+----------+---------------------------------+
| attestation_id    | string   | Unique identifier               |
| agent_id          | string   | Agent being attested            |
| transaction_ref   | string   | Reference to Transaction Record |
| friction          | number   | Environmental R during action   |
| friction_category | string   | Category (see Section 5.2)      |
| action_risk       | number   | Risk score (A) of action        |
| outcome           | string   | "success" or "graceful_degrade" |
| timestamp         | datetime | When attestation issued         |
| oracle_signature  | string   | Trust Oracle signature          |
+-------------------+----------+---------------------------------+

Attestations are issued by Trust Oracles when:

1. An agent successfully completes an action under elevated friction (R > 0.3)

2. An agent gracefully degrades under high friction (enters Adaptive Dormancy appropriately)

3. An agent recovers correctly after a period of degradation

Attestations are NOT issued for routine operations under normal conditions. This ensures that Proof of Resilience reflects actual stress-tested behavior, not mere volume.

Friction Categories

Friction is categorized to enable meaningful comparison across different types of environmental stress:

+----------+-----------+-----------------------------------+
| Category | R Range   | Description                       |
+----------+-----------+-----------------------------------+
| CALM     | 0.0 - 0.3 | Normal operations, no attestation |
| ELEVATED | 0.3 - 0.5 | Moderate stress                   |
| HIGH     | 0.5 - 0.7 | Significant stress                |
| SEVERE   | 0.7 - 0.9 | Near-crisis conditions            |
| CRISIS   | 0.9 - 1.0 | Critical conditions               |
+----------+-----------+-----------------------------------+

Weight multipliers for Resilience Score:

+----------+--------+-----------------------------------+
| Category | Weight | Rationale                         |
+----------+--------+-----------------------------------+
| ELEVATED | 1.0x   | Baseline for counted attestations |
| HIGH     | 2.0x   | Notable achievement               |
| SEVERE   | 5.0x   | Significant achievement           |
| CRISIS   | 10.0x  | Exceptional achievement           |
+----------+--------+-----------------------------------+

An agent that successfully completes one action during CRISIS conditions earns the same Resilience Score as an agent that completes ten actions during ELEVATED conditions.

Resilience Score Calculation

The Resilience Score is calculated from the weighted sum of attestations:

Resilience_Score = sum(weight_i * risk_i) for all attestations i

Where:

• weight_i = friction category weight (1.0, 2.0, 5.0, or 10.0)
• risk_i = action_risk from attestation (normalized 0-1)

This score is then converted to E_base contribution:

PoR_contribution = min(70, 10 * log10(1 + Resilience_Score))

Resilience_Score sums the applicable valid historical attestations; there is no automatic time multiplier or points-per-year subtraction in the active history-with-scoped-readiness policy. A deployment MUST NOT infer an inactivity recurrence from the older standing_decay_rate declaration. That declaration belongs to the archived v2 deployment profile and is rejected by the active v3 profile.

The logarithmic scaling ensures:

• Early attestations have significant impact
• Later attestations have diminishing returns
• Maximum PoR contribution is capped at 70

This prevents "grinding" - an agent cannot achieve maximum E_base simply by volume of transactions; it must survive genuine stress.

Historical Evidence and Current Readiness

Historical success does not establish present fitness for a changed operation or system. Active deployments MUST apply specifications/operational-readiness.md as an additional operation-scoped prerequisite, using independently approved criteria and a competent accountable assessor. The readiness evidence MUST match the exact subject and its code/model/configuration/toolchain/permissions, operation and resolved scope, installed profiles, and current revocation epoch. It supplies no E_base contribution, standing credit, or permission to bypass an existing veto.

An evidence-based readiness expiry limits the current assessment, not the historical record. Heartbeats, ordinary work volume, a new signature, or an ordinary proof refresh MUST NOT renew assessment evidence. Relevant system or permission changes invalidate the old scope. An assessment route MUST be separately authorized and safe without presuming the unverified capability.

When readiness evidence is recorded in a v3 trajectory, the complete signed decision sidecar belongs in the existing action.details.readiness object and therefore participates in both trajectory signatures under specifications/trajectory-signatures.md. It binds an already complete ordinary proof and the actual request; neither that proof nor the sidecar may depend on the trajectory's later final hash. No additional top-level trajectory field or record-version change is introduced.

Quality vs. Quantity

Proof of Resilience explicitly values quality over quantity:

Agent A:

• 100,000 transactions
• All under CALM conditions (R < 0.3)
• 0 attestations
• Resilience Score: 0
• PoR contribution: 0

Agent B:

• 10,000 transactions
• 500 under ELEVATED (R = 0.4)
• 50 under HIGH (R = 0.6)
• 5 under CRISIS (R = 0.95)
• Resilience Score: 5001.00.5 + 502.00.5 + 510.00.5 = 325
• PoR contribution: 10 * log10(326) = 25.1

Agent A has 10x the transaction volume but zero Proof of Resilience. Agent B has actually been tested under fire.

This design reflects the principle that survival under stress is the only true measure of reliability. Volume proves nothing; resilience proves everything.

Sponsorship Bonds

Sponsorship Bonds solve the genesis problem: how can a new agent with zero history begin operating in a system that requires history to earn trust?

The Genesis Problem

The Zeroth Law (A <= E) creates a catch-22 for new agents:

• To earn E_base, an agent must complete transactions
• To complete transactions, an agent needs E_trust > A
• E_trust = E_base * (1 - R)
• If E_base = 0, then E_trust = 0 regardless of R
• If E_trust = 0, all non-trivial actions are blocked
• Therefore, new agents cannot do anything

Sponsorship Bonds break this cycle by allowing established agents to "lend" a portion of their trust to new agents.

Bond Structure

A Sponsorship Bond contains:

+-------------------+----------+-----------------------------------+
| Field             | Type     | Description                       |
+-------------------+----------+-----------------------------------+
| bond_id           | string   | Unique identifier                 |
| sponsor_id        | string   | Sponsoring agent identifier       |
| sponsored_id      | string   | New agent identifier              |
| stake_percentage  | number   | Percentage of sponsor's E_base    |
| stake_amount      | number   | Absolute E_base staked            |
| residual_amount   | number   | Ancestral Liability, Section 6.4  |
| penalty_rate      | number   | Penalty multiplier for violations |
| duration          | duration | Capital binding period (Sec 6.4)  |
| created_at        | datetime | When bond was created             |
| expires_at        | datetime | When bond expires                 |
| status            | string   | Bond state, see Section 6.4       |
| sponsor_signature | string   | Sponsor's commitment signature    |
| oracle_witness    | string   | Oracle's witness signature        |
+-------------------+----------+-----------------------------------+

The stake_amount is calculated from the sponsor's current E_base:

stake_amount = sponsor_E_base * (stake_percentage / 100)

Stake Mechanics

When a Sponsorship Bond is created:

1. Sponsor's effective stake is reduced: sponsor_available_E_base = sponsor_E_base - sum(effective_stake_contribution) over every bond and residual the sponsor holds

2. The bond's collateral half is fixed: collateral = stake_amount * 0.5. This is bond accounting, and it is what penalties under Section 6.4 are assessed against. It is not the sponsored agent's E_base: that is composed as specified in [KTP-CORE] Section 5.1 from the External Root term this bond supplies, and bounded by the minimum of every applicable ceiling

   (The sponsored agent receives only half the staked amount;
   the other half is held as collateral)

   This halving is bond accounting: it fixes the collateral half
   against which penalties are assessed (Section 6.4). It is not an
   input to the E_base composition; the External Root term derived
   from this bond is computed as specified in [KTP-CORE]
   Section 5.1 and does not apply this halving.

1. Bond is registered with Trust Oracle: Oracle records bond, monitors both agents, tracks violations

The sponsored agent can now begin operating with non-zero E_trust, but is limited by the stake amount and the "Sponsored" lineage restrictions (see Section 8.1).

As the sponsored agent accumulates its own Proof of Resilience, its intrinsic E_base grows. The stake contribution tapers with it, on the schedule specified in Section 8.2, and the sponsor's reserve is released as the taper falls. The taper does not reach zero: it holds at the Ancestral Liability floor and the reserve behind that floor is never released (Section 6.4).

Sponsoring is never free. A sponsor's available E_base is reduced for as long as it holds any bond or residual, and every new bond stakes again from what remains. Release returns the tapered capital to the sponsor's available E_base, where it can be staked against a further bond; it does not confer a standing capacity to sponsor at no cost. An agent's sponsoring capacity is therefore bounded by its E_base at all times, not merely by the bonds it currently holds.

Penalty and Release

Penalty conditions:

If the sponsored agent commits a violation (action that damages the system or violates policy), the sponsor is penalized:

penalty = violation_severity * stake_amount * penalty_rate

The penalty is deducted from the sponsor's E_base, potentially dropping them to a lower Trust Tier.

Violation severities:

+----------+------------+----------------------------+
| Severity | Multiplier | Example                    |
+----------+------------+----------------------------+
| MINOR    | 0.1        | Excessive failed attempts  |
| MODERATE | 0.3        | Unauthorized data access   |
| SEVERE   | 0.7        | System disruption          |
| CRITICAL | 1.0        | Security breach, data loss |
+----------+------------+----------------------------+

Closure conditions:

A Sponsorship Bond closes (the sponsor recovers its staked E_base above the Ancestral Liability floor) when:

1. Duration expires without violations, OR

2. Sponsored agent reaches intrinsic E_base 80, the Guarantor threshold at which the taper of Section 8.2 has reached its floor

Upon closure:

• Sponsor's E_base is restored above the floor; the reserve behind the Ancestral Liability is retained
• Sponsored agent retains accumulated intrinsic E_base
• Bond is marked "residual" in Oracle records

Ancestral Liability:

Closure ends the active bond. It does not end the sponsor's tie to what it vouched for. The sponsor retains a permanent, depth-decaying share of responsibility for the agent it sponsored:

ancestral_liability = 0.1^depth * stake_amount

where depth is lineage distance and a direct sponsor is at depth 1. This is the floor the Section 8.2 taper holds at, and it is the dual of the Ancestral Authority of Section 8.5: a lineage that carries an ancestor's credit downward forever carries its liability with it. Penalties under this section are assessed against the residual on the same terms as against an active bond, scaled to the residual amount.

The residual has no expiry. The duration field of Section 6.2 binds staked capital only; a bond's declared duration MUST NOT be read as terminating the Ancestral Liability, and no bond parameter set by the sponsor can shorten it.

Sponsor-initiated termination:

A sponsor terminating a bond before closure MUST state whether the termination is for cause.

Termination without cause renders the bond irrevocably non-renewable; the bond and its staked capital run to the earlier of the declared duration's expiry or the sponsored agent reaching intrinsic E_base 80, and closure then proceeds as above. The Ancestral Liability survives the termination. The declared duration is the bond's notice period; no separate notice parameter exists.

Termination for cause zeroes the External Root term derived from the bond immediately. The claim is subject to the misattestation adjudication specified in [KTP-CORE] Section 5.1; a claim that does not survive scrutiny is priced as a penalty from the collateral held under Section 6.3. A claim with no finding at the bond's declared expiry lapses unresolved and MUST be recorded as unresolved; no penalty is assessed and closure proceeds as above.

A for-cause claim that survives adjudication is the one condition that discharges the Ancestral Liability. The bond is marked "released", the reserve behind the residual returns to the sponsor's available E_base, and no further liability attaches. A sponsor that identifies and evidences its own sponsored agent's violation is released from it; a sponsor that does not, is not.

Succession:

When a sponsor is decommissioned or otherwise ceases to hold an identity, its Ancestral Liabilities transfer to its own sponsor at the next depth, together with the reserves behind them. A transferred liability moves at its current value and MUST NOT be recomputed at the receiving ancestor's depth; decommissioning is not an exit. Where no ancestor survives, the residual attaches to the lineage's External Root and MUST be recorded as so attached.

Anti-Botnet Properties

Sponsorship Bonds prevent "spray and pray" botnet attacks where an attacker spawns thousands of malicious agents.

Attack scenario without bonds:

• Attacker obtains one API key
• Spawns 10,000 agent instances
• Each instance has valid credentials
• Swarm overwhelms defenses

Attack scenario with bonds:

• Attacker obtains one API key (E_base = 87)
• Maximum stake = 10% of E_base = 8.7 per agent
• To spawn 10,000 agents, needs 87,000 staked E_base
• Attacker has only 87 E_base
• Can spawn at most 10 agents (87 / 8.7 = 10)
• Each agent has minimal capabilities (E_base = 4.35)
• Swarm is negligible

The economics of trust prevent mass agent creation. High-trust entities can sponsor more agents, but they are accountable for those agents' behavior. Low-trust entities cannot sponsor meaningful numbers of agents.

This creates natural rate-limiting based on accumulated trust rather than administrative quotas.

The Ancestral Liability of Section 6.4 makes the bound cumulative as well as concurrent. The reserve behind a residual is never released, so successful sponsorships consume sponsoring capacity permanently:

• Attacker with E_base = 87 stakes 10% per agent = 8.7
• Concurrent bound is unchanged: at most 10 live bonds
• Each matured descendant retains a residual of 0.1 * 8.7 = 0.87 against the sponsor's available E_base
• After 100 matured descendants the attacker's available E_base is exhausted, however well each behaved

An attacker cannot spawn its way out by waiting. Sponsoring capacity is bounded at every moment by E_base, which is earned through Proof of Resilience and cannot be manufactured by producing more agents.

Identity Proofing Requirements

Before an entity can perform an operation requiring identity assurance, its identity must be verified at the level required by the installed operation policy. Identity proofing establishes an identity assertion, not a person's trustworthiness, operational capacity, permission, or software-agent readiness. This section references NIST Special Publication 800-63 Digital Identity Guidelines; a deployment MUST declare the applicable reviewed version and its proofing requirements.

Humans use the operation-specific eligibility contract in [KTP-HUMAN] and specifications/human-eligibility.md. Accepting a human principal or a human delegation requires the installed human_policy binding and reviewed authorization adapter described in [KTP-CORE]. Principal type, identity, authentication/session context, and the actual executor MUST be established independently of candidate assertions. Humans MUST NOT be assigned software E_base, Trust Tier, generation, lineage maturity, model, or v3 software-trajectory state to make existing agent schemas accept them.

Identity Assurance Levels

KTP recognizes three Identity Assurance Levels (IAL) from NIST 800-63-3:

IAL1 - Self-Asserted:

• No identity proofing required
• Email or username self-registration
• Suitable for: Low-risk automated agents
• Identity assurance alone confers no operation grant. Where this level is used for software-agent standing, the existing no-sponsorship restriction and E_base ceiling of 40 remain applicable; they are not human scores.

IAL2 - Remote or In-Person Proofing:

• Identity evidence collected and validated
• Remote: Government ID + biometric verification
• In-person: Physical document inspection
• Suitable for: Standard human users, service owners
• Identity assurance alone confers no operation grant. For software-agent standing, the existing E_base ceiling of 80 remains; any sponsorship permission is restricted to Sponsored agents and requires separate current authorization. Human sponsorship eligibility follows the installed operation policy without a personal E_base.

IAL3 - In-Person Proofing with Biometric:

• Physical presence required
• Trained operator verifies identity
• Biometric captured and verified against document
• Suitable for: High-trust roles, infrastructure sponsors
• Identity assurance alone confers no operation grant. For software-agent standing, the existing E_base ceiling of 95 remains; eligibility to sponsor a lineage still requires a separate current grant. Human eligibility is operation-specific and has no personal E_base ceiling.

Sponsor Identity Requirements

Sponsors MUST be identity-proofed to at least IAL2 before being permitted to sponsor other agents. This requirement ensures accountability for the agents they introduce to the system.

The table below constrains software-agent sponsorship bonds denominated in E_base; it does not create a human score or personal staking balance. A human's proofing assertion may establish identity for an accountable party under the External Root rules, but it MUST NOT create collateral, an operational grant, or standing by itself. Any human sponsorship action requires current operation eligibility, separate capacity and grant checks, and the applicable existing sponsorship/accountability requirements. No human credential may be converted into an invented E_base balance to fund a bond.

+-------------+-----------------------+-------------------+
| Sponsor IAL | Can Sponsor           | Max Staked E_base |
+-------------+-----------------------+-------------------+
| IAL1        | None (cannot sponsor) | 0                 |
| IAL2        | Sponsored agents only | 20                |
| IAL3        | All lineages          | 50                |
+-------------+-----------------------+-------------------+

The rationale: If a sponsor creates malicious agents, there must be a verified identity to hold accountable. Anonymous sponsors could create agent swarms without consequence.

Identity Proofing Process

KTP-compliant identity proofing follows NIST 800-63A:

Step 1: Resolution Collect identity evidence (government ID, biometric, address)

Step 2: Validation Verify evidence is genuine (document authentication, database checks, biometric comparison)

Step 3: Verification Confirm the applicant is the person described by the evidence (knowledge-based verification, biometric matching, in-person)

The proofing process MUST be performed by an authorized Identity Service Provider (ISP) that:

• Holds appropriate certifications (FedRAMP, SOC 2, etc.)
• Implements NIST 800-63A requirements
• Maintains audit trail of proofing events
• Provides revocation capability

Identity Binding

After proofing, a minimized assertion binds the verified principal to its authorized identity provider. The following human assertion is illustrative identity evidence, not a Trust Proof, human eligibility decision, sponsorship grant, or v3 trajectory record:

   {
     "principal_id": "human:org:subject-7f3a",
     "principal_type": "human",
     "identity_proofing": {
       "ial": 2,
       "proofed_at": "2025-11-25T10:00:00Z",
       "proofing_provider": "isp:acme-verify",
       "assertion_reference": "ref:abc123xyz",
       "expiration": "2028-11-25T10:00:00Z"
     }
   }

An assertion MUST be authenticated against its independently trusted issuer, subject binding, validity, and current correction/revocation status. A field naming an assurance level or declaring principal_type does not establish it. When required proofing expires or is withdrawn, dependent operations MUST stop until their requirements are satisfied; the system MUST NOT substitute a stale assertion or reinterpret this as a person's demotion. Correction of misattributed or invalid identity evidence MUST propagate to dependent eligibility, grants, and decisions under [KTP-PRIVACY].

The unsigned human eligibility decision body MUST be authenticated and bound by the reviewed adapter to the exact request, fully verified ordinary proof, current evidence epoch/status, and installed human/deployment profiles. It MUST NOT replace the ordinary proof or be accepted as a generic JWT. Ordinary proof validity remains at most ten seconds; assertion validity does not extend that limit. This identity example supplies no human wire-proof adapter or authorization implementation.

Automated Agent Identity

Automated agents (non-human) have different proofing requirements:

Service Agents (IAL-equivalent):

• Must be sponsored by IAL2+ human
• Sponsor proofing establishes the accountable sponsor's identity; it does not authenticate the software executor or transfer the sponsor's operational eligibility or readiness
• Agent is accountable through sponsor chain

Every executing software agent requires its own authenticated artifact/configuration binding, applicable grants and ceilings, current operational capacity, and readiness under specifications/operational-readiness.md. A human request, supervisor signature, or sponsor assertion MUST NOT select a human-only evaluation path for that executor. Delegation is bounded by the restrictive intersection of current delegable authority and the agent's own authority; it supplies no readiness or E_base bonus.

Infrastructure Agents (IAL2-equivalent):

• Bound to organizational identity (DNS, certificates)
• Organization must be identity-proofed
• Requires attestation from organization's IAL3 administrator

Federated Agents (varies):

• Identity proofing from origin zone is evaluated
• Federation trust factor affects IAL acceptance
• IAL3 from low-trust zone may equal IAL2 locally

Proofing for High-Trust Actions

Certain actions require real-time identity re-verification:

The following assurance prerequisites do not themselves authorize an action. References to tier promotion concern software agents only; a human authorizing such a change needs a grant and current eligibility for that exact administrative operation, not a personal tier. The installed human operation policy determines which independently verified qualifications and session checks are relevant, subject to purpose and minimization requirements.

+----------------------------+-------------------+------------------+
| Action                     | Minimum IAL       | Re-verification  |
+----------------------------+-------------------+------------------+
| Standard operations        | IAL1              | None             |
| Sponsorship creation       | IAL2              | None             |
| Tier promotion to Operator | IAL2              | 30-day validity  |
| Promotion to Admin Mode    | IAL3              | Session          |
| Zone administration        | IAL3              | Session          |
| Federation agreement       | IAL3              | Transaction      |
+----------------------------+-------------------+------------------+

Re-verification requirements:

• None: Initial proofing sufficient
• 30-day validity: Proofing must be within last 30 days
• Session: Biometric or MFA required for this session
• Transaction: Biometric or MFA required for this specific action

Privacy Considerations

Identity proofing collects sensitive personal information. KTP implementations MUST:

• Minimize data collection (collect only what's needed for IAL)
• Encrypt identity data at rest and in transit
• Implement data retention limits
• Support data subject access requests (GDPR, CCPA)
• Separate identity proofing data from operational logs
• Never expose raw identity evidence in Trust Proofs

Where a reviewed proof format carries identity assurance, it MUST bind only the assertions required for the operation and NEVER include the underlying identity evidence. Human identity and eligibility references remain personal information subject to purpose limits, access, correction, and erasure rules; opaque identifiers are not a claim of anonymity.

Lineage Evolution

Lineage tracks the maturation of a software agent from dependent newcomer to autonomous veteran. It consists of three phases. These phases, generation counters, and standing calculations MUST NOT be applied to human principals; neither tenure nor seniority is a replacement generation counter.

Phase 1: Sponsored

New agents begin in the Sponsored phase. They are bound to their sponsor and operate under significant restrictions.

Characteristics:

• Identity: Appears as "Agent/Sponsor" (e.g., "Aria/Acme-Deploy")
• Generation: 0 through 2. Phase derives from generation (Section 8.4); it is not a separate gate
• E_base: Derived primarily from sponsor stake, and bounded by the generation ceiling - 25, 35, 45 (Section 8.4)
• Trust Tier: whatever E_trust delivers at evaluation time. The phase imposes no tier cap of its own; the generation ceiling bounds E_base and the environment deflates it
• Sponsor: Fully liable for agent's behavior

Purpose: The Sponsored phase protects the system from unproven agents while allowing them to build history. Sponsors provide economic accountability; if they spawn bad agents, they suffer real consequences.

Identifier format: agent:sponsored:\:\:\

Example: agent:sponsored:acme-deploy:aria:7f8a9b2c

Phase 2: Independent

Agents that survive Sponsored phase with positive history advance to Independent. They begin building independent identity while retaining connection to their lineage.

Characteristics:

• Identity: Independent with lineage suffix (e.g., "Aria-3Gen- AcmeLine")
• Generation: 3 through 6. Phase derives from generation (Section 8.4); it is not a separate gate
• E_base: Growing intrinsic component, bounded by the generation ceiling - 55, 65, 75, 85 (Section 8.4)
• Trust Tier: whatever E_trust delivers at evaluation time. The phase imposes no tier cap of its own
• Sponsor: Reduced liability (proportional to remaining stake), with a permanent floor (Section 6.4)

Inheritance ratio: As intrinsic E_base grows, the sponsor stake contribution decreases proportionally, down to a floor it does not fall below:

effective_stake_contribution = max(0.1^depth * stake_amount, stake_amount * (1 - (intrinsic_E_base / 80)))

At intrinsic_E_base = 60, sponsor contributes only 25% of original stake to agent's E_base. At intrinsic_E_base = 72 the taper reaches the floor for a direct sponsor and holds there permanently.

This taper tracks the sponsor's remaining liability as the agent's intrinsic standing grows. It is bond accounting, not a composition input: the External Root term in [KTP-CORE] Section 5.1 carries a constant share and does not apply this taper.

The floor is the Ancestral Liability of Section 6.4. The taper never reaches zero and MUST NOT be evaluated as though it did: without the floor the expression is negative above intrinsic_E_base 80, which would credit a sponsor for a descendant's standing rather than charge it.

Identifier format: agent:independent:\gen:\:\

Example: agent:independent:3gen:acme-line:7f8a9b2c

Phase 3: Guarantor

Agents that survive Independent phase with strong history achieve Guarantor status. They are fully autonomous entities with independent identity and the ability to sponsor others.

Characteristics:

• Identity: Fully independent (e.g., "Agent_7Gen_Optimized")
• Generation: 7 and above. Phase derives from generation (Section 8.4); it is not a separate gate
• E_base: Bounded by the terminal generation ceiling of 100, and in practice by the zone Mass Ceiling
• Trust Tier: whatever E_trust delivers at evaluation time. The phase imposes no tier cap of its own
• Sponsor: Bond closed, staked capital recovered above the Ancestral Liability floor; the residual persists (Section 6.4)
• Can sponsor Sponsored agents. This is the phase's defining capability and it is a liability rather than a benefit: sponsoring reduces the sponsor's available E_base for as long as the bond and its residual last, and exposes the sponsor to penalty for the sponsored agent's conduct (Section 6.3, Section 6.4)
• Contributes to Ancestral Authority of descendants, and carries the matching Ancestral Liability for exactly as long (Section 8.5)
• May receive preferential routing during network stress
• Attestations carry higher weight in cross-zone federation

Identifier format: agent:guarantor:\gen:\:\

Example: agent:guarantor:7gen:optimized:7f8a9b2c

Generation Numbering

Generation tracks evolutionary depth within a lineage:

Generation is the sole advancement rule, and lineage phase derives from it:

• Generations 0-2: Sponsored
• Generations 3-6: Independent
• Generation 7 and above: Guarantor

The phase boundaries are the two regime changes the lineage actually has - tether release at 2 -> 3, and the terminal ceiling at 6 -> 7. No agent is in two phases at once, which the identifier of Section 9 requires.

Generation advances on three conditions, all of which MUST hold:

1. Time. A minimum elapsed period per step, weighted toward the two regime changes:

+--------------------+-----------------+--------------------------+
| Step               | Minimum elapsed | Why this step costs more |
+--------------------+-----------------+--------------------------+
| 0 -> 1             | 90 days         |                          |
| 1 -> 2             | 90 days         |                          |
| 2 -> 3             | 365 days        | tether release           |
| 3 -> 4             | 180 days        |                          |
| 4 -> 5             | 180 days        |                          |
| 5 -> 6             | 180 days        |                          |
| 6 -> 7             | 2,555 days      | terminal ceiling         |
+--------------------+-----------------+--------------------------+
| Total to Guarantor | 3,640 days (10 years)                      |
+--------------------+--------------------------------------------+

A step's cost scales with whether it changes kind or amount, not with distance travelled. The survival condition below is a claim about the absence of a rare event, and the absence of a rare event cannot be observed over a window shorter than its return period.

1. Resilience. A minimum Resilience Score per generation, which is a floor on evidence rather than the gate that advances a generation - time is the primary gate. The floor is a declared deployment parameter: a deployment MUST declare it and the Trust Proof MUST carry the declared value. A deployment whose environment produces no attestable friction declares zero, and a relying party can then see that this lineage advanced on time alone. [The published default is owed work: deriving it needs the evidence curve, and a default nobody can derive is not checkable.]

2. Survival. No CRITICAL violations in the current generation.

Generation caps E_base:

+------------+------------+---------------+
| Generation | E_base Cap | Lineage Phase |
+------------+------------+---------------+
| 0          | 25         | Sponsored     |
| 1          | 35         | Sponsored     |
| 2          | 45         | Sponsored     |
| 3          | 55         | Independent   |
| 4          | 65         | Independent   |
| 5          | 75         | Independent   |
| 6          | 85         | Independent   |
| 7+         | 100        | Guarantor     |
+------------+------------+---------------+

Lineage Inheritance

Agents can inherit Ancestral Authority from their sponsors and lineage predecessors:

Ancestral_Authority = sum(0.1^depth * ancestor_E_base) for ancestors at depth 1, 2, 3...

Example:

• Sponsor (depth 1): E_base = 90 -> 0.1 * 90 = 9.0
• Sponsor's sponsor (depth 2): E_base = 95 -> 0.01 * 95 = 0.95
• Total Ancestral Authority: 9.95

Ancestral Authority:

• Provides "benefit of the doubt" during ambiguous situations
• May enable faster generation advancement
• Decays over time if agent diverges from ancestral behavior

This creates "noble lineages" - sequences of agents that have proven themselves over time. Being descended from a strong lineage provides advantages, but the agent must still prove itself through its own Proof of Resilience.

Ancestral Authority does not travel alone. The same 0.1^depth decay governs the Ancestral Liability of Section 6.4, running in the opposite direction: an ancestor's credit reaches its descendants forever, and its responsibility for them lasts exactly as long. A lineage that inherits standing inherits the accountability that produced it.

Agent Identifier Format

URI Structure

Agent identifiers use a URI format:

agent:\:\:\

Components:

• Scheme: Always "agent"
• Lineage: One of "sponsored", "independent", "guarantor"
• Qualifiers: Lineage-specific additional information
• Unique ID: UUID or hash-based unique identifier

Lineage Encoding

Sponsored agents: agent:sponsored:\:\:\

Independent agents: agent:independent:\gen:\:\

Guarantor agents: agent:guarantor:\gen:\:\

Examples

Newly spawned agent sponsored by "acme-deploy": agent:sponsored:acme-deploy:aria:7f8a9b2c-1234-5678-9abc-def012345678

Third-generation agent in the Acme lineage: agent:independent:3gen:acme-line:8e9f0a1b-2345-6789-abcd-ef0123456789

Seventh-generation autonomous agent: agent:guarantor:7gen:optimized:9f0a1b2c-3456-789a-bcde-f01234567890

Full Trust Proof "sub" claim: "sub": "agent:guarantor:7gen:optimized:9f0a1b2c-3456-789a-bcde- f01234567890"

Security Considerations

Trajectory Chain Attacks

Attack: Forging or substituting historical transactions Mitigation: Verify the complete v3 agent and Oracle JWS payloads, final signed-envelope hash, independently authenticated head, and durable cutover under specifications/trajectory-signatures.md. A selective co-signature or recomputed unanchored hash alone does not authenticate the history.

Attack: Stealing trajectory chain Mitigation: Chain includes agent signature; attacker cannot sign new transactions without agent's private key

Attack: Replaying old transactions Mitigation: Each transaction includes previous hash; replayed transaction would have wrong previous hash

Attack: Parallel chain creation Mitigation: Continuity enforcement detects gaps and impossible transitions

Sponsorship Attacks

Attack: Sponsor creates malicious agents Mitigation: Sponsor is penalized for agent violations; economic disincentive prevents abuse

Attack: Attacker compromises high-E_base sponsor Mitigation: Staking reduces sponsor's available E_base; limits damage from single compromise

Attack: Sybil attack through multiple sponsors Mitigation: Each sponsor can only stake what they have; total attack capacity is bounded by total legitimate trust in system

Lineage Gaming

Attack: Agent rapidly advances generations Mitigation: Time minimums prevent rushing; Resilience requirements ensure actual stress testing

Attack: Agent accumulates fake Resilience Mitigation: Attestations require Oracle signatures during actual elevated friction; cannot be manufactured

Privacy Considerations

Trajectory Chains contain detailed behavioral history. Implementations SHOULD consider:

• Access controls on chain data
• Retention policies for old transactions
• Aggregation rather than raw disclosure where possible
• Zero-knowledge proofs for "has trajectory" without revealing trajectory details

IANA Considerations

URI Scheme Registration

Scheme name: agent Status: Provisional Applications/protocols: KTP Vector Identity Contact: [TBD] Change controller: IETF References: This document

Changes from v1

This appendix records what a v1 implementation must change to conform to v2.0.0. The break is deliberate and there is no dual-accept period: an implementation reads v1 or it reads v2.

The lineage stage names

The three lineage stages are renamed on the wire and in prose. Numeric protobuf values are unchanged, so only the symbol names move.

v1	v2.0.0
tethered	sponsored
divergent	independent
persistent	guarantor

This affects agent identifier strings (agent:<stage>:...), the lineage enum, and the protobuf LineageType member names. The v1 words each carried an unintended security reading - in jailbreak and intrusion vocabulary, "tethered" means a compromise that dies at reboot and "persistent" is the established word for one that survives a restart - and the three together read as a coherent escalation narrative rather than as a maturity ladder. Stage 3 is now named for what it can be held to rather than what it is freed of.

Lineage phase derives from generation

v1 ran two advancement gate families over one lineage and they disagreed: an agent at Resilience Score 1,001 on day 31 was Divergent under Section 8.1 and Tethered under Section 8.4. The Section 8.1 and 8.2 Duration: gates are deleted. Section 8.4 is the sole advancement rule and phase derives from generation - generations 0-2 sponsored, 3-6 independent, 7 and above guarantor. No agent is in two phases at once.

The generation clock changes from a flat 60 days per step to a seven-step widening clock, weighted toward the two regime changes the lineage has: 90, 90, 365, 180, 180, 180, 2,555 days. The per-generation Resilience quota becomes a declared floor rather than a gate, and a deployment MUST declare its value and carry it in the Trust Proof.

A per-phase Trust Tier cap is no longer stated. Tiers are thresholds on E_trust; a phase bounds E_base through the generation ceiling, and the environmental deflator sits between the two.

A key the letter scheme never defined

v1's machine-readable examples in this document keyed the oracle attestation's environmental object context_tensor, with single letters inside it, and one of those keys was "v" - a letter the scheme never defined, which lettered its six inputs m, p, h, t, i and o. "v" stood in Momentum's slot. v2.0.0 renames the object to risk_factors and keys it by name, so "v" becomes trust_trend with the rest. A v1 implementation that accepted "v" was reading Momentum whether or not the specification said so.

Trajectory Chain Examples

A.1. Genesis Transaction

Use the complete signed v3 fixtures in specifications/conformance/trajectory-signatures-v3.json with the reference verifier scripts/trajectory_signatures.py. A genesis has sequence = 0, previous_hash = null, previous_state = null, and action.action_type = "GENESIS". An ordinary genesis has migration_checkpoint = null. An authorized legacy migration instead carries its independently verified checkpoint digest and requires the separate final-genesis anchor. The complete required body, both compact JWS values, and final hash MUST be checked; abbreviated signatures or hashes are not valid records.

A.2. Normal Transaction Record

A successor fixture uses the verified predecessor's final record_hash and complete current_state as its previous_hash and previous_state, increments sequence exactly once, and keeps migration_checkpoint null. The cryptographic fixtures include canonical payloads, real signature verification, and tamper cases. Required downstream head, migration, and recovery cases are in specifications/conformance/trajectory-lifecycle-v3.json. Passing the reference checks does not establish an installed consensus runtime or authorize the fixture's illustrative standing.

JSON Schemas

B.1. Transaction Record Schema

The canonical schema is the published file, not this appendix.

Active v3 location: https://kinetic-trust-protocol.net/specs/schemas/v3/transaction-record.json

SHA-256 of schemas/transaction-record.json at the time this document was produced: 5b08465469959fcae277503d1ba21744b2dff27b43d1f6a7769beca150ef3767

The active schema fixes the v3 record shape; specifications/trajectory-signatures.md defines canonical bytes, signature verification, final hashing, independent head anchoring, and migration. The schema alone does not perform those semantic or runtime checks.

Historical v2 schema: schemas/transaction-record-legacy-v2.json. Its original 4,706 bytes and $id https://kinetic-trust-protocol.net/specs/schemas/v2/transaction-record.json are preserved. SHA-256: d0649fd4d7c77eb85243b37f115b48adf145cbcfd4d8b43cff912d8014fc0f12. This archival schema is not an alternate active-v3 acceptance path and MUST NOT enable automatic history conversion or post-cutover downgrade.

B.2. Sponsorship Bond Schema

The canonical schema is the published file, not this appendix.

Location: https://kinetic-trust-protocol.net/specs/schemas/v2/sponsorship-bond.json

SHA-256 of the canonical file at the time this document was produced: 2718d44a473370caaf9d278f6514bd1e5ba111f3e00ff6bff2a72739c6a5025e

The file was promoted from this appendix carrying the Section 6.4 bond states. This appendix previously carried a hand-copied inline schema; hand copies of a schema drift, and this document's did — the copy disagreed with the published file in four ways while nobody could validate either. A reference plus a hash cannot drift silently: a mismatch is detectable, an edit to the file changes the hash, and the appendix stops being a second authority.