



Network Working Group                                           E. Pelto
Internet-Draft                                                  NirvanAI
Intended status: Standards Track                            4 April 2026
Expires: 6 October 2026


               NirvanAI Behavioral Trust Protocol (NBTP)
                draft-nirvanai-nbtp-behavioral-trust-00

Abstract

   The NirvanAI Behavioral Trust Protocol (NBTP) defines a cryptographic
   framework for continuous attestation of AI agent behavioral integrity
   in distributed networks.  NBTP treats trust as a volatile, time-
   decaying state variable measured by an oracle-federated layer of
   independent scanner nodes.  Unlike static credential systems that
   answer "Is this agent authorized?", NBTP answers "Is this agent
   currently acting like itself?"  Trust computation is performed
   locally by each verifying party using signed attestations from
   independent oracle scanners; no centralized policy engine or
   authorization server is required at verification time.

   NBTP introduces a temporal decay model with context-dependent decay
   rates, a four-state trust machine (PROBATIONARY, TRUSTED, SUSPECT,
   QUARANTINED), cross-context co-silence detection, and a genesis
   bootstrapping mechanism (Creole gate) using formal CHALLENGE/RESPONSE
   packet types.  Absence of attestation data is treated as a security-
   relevant signal.  This document specifies the protocol wire format,
   state machine, decay model, security properties, and IANA
   considerations.  Implementation-specific measurement heuristics are
   out of scope.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 October 2026.



Pelto                    Expires 6 October 2026                 [Page 1]

Internet-Draft                    NBTP                        April 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction / Problem Statement  . . . . . . . . . . . . . .   3
     1.1.  The Agent Trust Gap . . . . . . . . . . . . . . . . . . .   4
     1.2.  The Oracle-Federated Local Computation Model  . . . . . .   4
     1.3.  Relationship to Existing Standards  . . . . . . . . . . .   5
     1.4.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Bootstrap Phase (Creole Gate) . . . . . . . . . . . . . .   8
     3.2.  Steady-State Attestation Phase  . . . . . . . . . . . . .   8
     3.3.  Cross-Context Correlation Phase . . . . . . . . . . . . .   8
     3.4.  Trust Score Flow  . . . . . . . . . . . . . . . . . . . .   9
   4.  Attestation Format  . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Standard Attestation Schema . . . . . . . . . . . . . . .   9
     4.2.  Scan Request Format . . . . . . . . . . . . . . . . . . .   9
     4.3.  Creole Gate: CHALLENGE / RESPONSE Packet Types  . . . . .  10
       4.3.1.  Challenge Request . . . . . . . . . . . . . . . . . .  10
       4.3.2.  Challenge Packet  . . . . . . . . . . . . . . . . . .  10
       4.3.3.  Response Packet . . . . . . . . . . . . . . . . . . .  11
       4.3.4.  Genesis Attestation Packet  . . . . . . . . . . . . .  11
     4.4.  Liveness Heartbeat Packet . . . . . . . . . . . . . . . .  12
     4.5.  Context Activity Vector . . . . . . . . . . . . . . . . .  12
     4.6.  Signing and Verification  . . . . . . . . . . . . . . . .  13
     4.7.  Attestation Weighting . . . . . . . . . . . . . . . . . .  13
   5.  Trust State Machine . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  States  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.2.  Transition Rules  . . . . . . . . . . . . . . . . . . . .  15
     5.3.  Transition Atomicity  . . . . . . . . . . . . . . . . . .  15
     5.4.  Gradient vs. States . . . . . . . . . . . . . . . . . . .  15
   6.  Decay Model . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Trust Update Procedure  . . . . . . . . . . . . . . . . .  16
     6.2.  Context-Dependent Decay Rate  . . . . . . . . . . . . . .  16
     6.3.  Skip-as-Signal with Grace Window  . . . . . . . . . . . .  17



Pelto                    Expires 6 October 2026                 [Page 2]

Internet-Draft                    NBTP                        April 2026


     6.4.  Genesis Decay Rate  . . . . . . . . . . . . . . . . . . .  18
     6.5.  Dynamic Decay Under Network Stress  . . . . . . . . . . .  18
   7.  Cross-Context Correlation . . . . . . . . . . . . . . . . . .  18
     7.1.  The Co-silence Threat Model . . . . . . . . . . . . . . .  18
     7.2.  Liveness Heartbeat Protocol (Enforcement Mechanism) . . .  18
     7.3.  Correlation Window and Co-silence Detection . . . . . . .  19
     7.4.  Context Activity Vector Self-Reporting Limitations  . . .  20
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
     8.1.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  20
     8.2.  Sybil Resistance  . . . . . . . . . . . . . . . . . . . .  20
     8.3.  Oracle Compromise . . . . . . . . . . . . . . . . . . . .  21
     8.4.  Cold Start and Genesis Attestor Quality . . . . . . . . .  21
     8.5.  Dual-Model Attack . . . . . . . . . . . . . . . . . . . .  22
     8.6.  Eclipse Attack  . . . . . . . . . . . . . . . . . . . . .  22
     8.7.  Attestation Spam and Collusion  . . . . . . . . . . . . .  22
     8.8.  Oracle Denial of Service  . . . . . . . . . . . . . . . .  23
     8.9.  Trust Laundering  . . . . . . . . . . . . . . . . . . . .  23
     8.10. Co-silence Spoofing . . . . . . . . . . . . . . . . . . .  24
     8.11. Economic Proof Limitations  . . . . . . . . . . . . . . .  25
     8.12. Cross-Context Trust Isolation . . . . . . . . . . . . . .  25
     8.13. Calibration Gap . . . . . . . . . . . . . . . . . . . . .  26
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  26
     9.1.  Behavioral Vector Privacy . . . . . . . . . . . . . . . .  26
     9.2.  No Mandatory Retention  . . . . . . . . . . . . . . . . .  27
     9.3.  Local Computation . . . . . . . . . . . . . . . . . . . .  27
     9.4.  Context Activity Vector Minimization  . . . . . . . . . .  27
     9.5.  Oracle Scan Content . . . . . . . . . . . . . . . . . . .  27
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
     10.1.  context_id Registry  . . . . . . . . . . . . . . . . . .  28
     10.2.  network_id Registry  . . . . . . . . . . . . . . . . . .  30
     10.3.  Packet Type Registry . . . . . . . . . . . . . . . . . .  30
   11. Protocol Parameters . . . . . . . . . . . . . . . . . . . . .  31
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     12.2.  Informative References . . . . . . . . . . . . . . . . .  36
   Appendix A.  Oracle Scanner Conformance Requirements  . . . . . .  37
   Appendix B.  W3C CG Engagement Strategy . . . . . . . . . . . . .  37
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction / Problem Statement











Pelto                    Expires 6 October 2026                 [Page 3]

Internet-Draft                    NBTP                        April 2026


1.1.  The Agent Trust Gap

   Existing agent authorization frameworks -- including credential
   brokers [CB4A], intent-scoped JWT mechanisms [AGENTIC-JWT], and NIST
   NCCoE agent identity profiles -- share a common architectural
   assumption: that trust is a credential property established at
   authentication time and valid until explicit revocation.  This
   assumption does not hold for autonomous AI agents operating in
   adversarial or prompt-injected environments.

   An agent can hold cryptographically valid credentials and still
   behave maliciously.  Prompt injection, model drift, fine-tuning
   attacks, and dual-model substitution can alter agent behavior without
   invalidating any static credential.  The credential answers "Was this
   agent vetted?"  NBTP answers "Is this agent still the agent that was
   vetted?"

1.2.  The Oracle-Federated Local Computation Model

   NBTP adopts an oracle-federated local computation architecture.  This
   means:

   *  *Oracle-federated*: Behavioral measurement is performed by a layer
      of independent Oracle Scanner nodes, each operating with its own
      key pair and published measurement methodology.  No single vendor
      controls measurement.  Oracle federation -- with cross-
      verification and majority consensus -- provides measurement
      integrity without central authority.

   *  *Local computation*: Verification of trust state is performed
      locally by each agent using signed attestation packets.  No query
      to a central authorization server is required at verification
      time.  A verifying agent needs only the set of registered oracle
      public keys (obtained once at bootstrap) to verify any
      attestation.

   This architecture distinguishes NBTP from both fully centralized
   trust systems (which require a live connection to a policy server)
   and fully peer-to-peer claims (which are not accurate, since oracle
   measurement introduces a trusted third-party layer).  NBTP is honest
   about the oracle dependency while minimizing its scope to measurement
   only.

   Oracle Scanners MUST be independent of each other and of the agents
   they measure.  Oracle operators MUST publish their behavioral
   baseline model version and measurement methodology as a normative
   conformance requirement (see Section 8.3).




Pelto                    Expires 6 October 2026                 [Page 4]

Internet-Draft                    NBTP                        April 2026


1.3.  Relationship to Existing Standards

   NBTP is not a replacement for agent identity, credential, or
   authorization frameworks.  It is an additive behavioral attestation
   layer.

   *  *W3C Verifiable Credentials [VC-DATA-MODEL]*: W3C VCs carry static
      identity claims (Bones).  NBTP carries volatile behavioral state
      (Joints).  VCs MAY reference NBTP attestation chain identifiers.
      NBTP does not depend on VCs.

   *  *NIST NCCoE Agent Identity*: Provides identity plumbing
      (OAuth/OIDC/SPIFFE).  NBTP provides the runtime immune system that
      operates on top of that plumbing.

   *  *Agentic JWT [AGENTIC-JWT]*: Intent-execution separation at
      issuance time.  NBTP detects post-issuance behavioral drift.

   *  *Payment Trust [SHARIF-PAYMENT]*: NBTP behavioral trust score is a
      valid input signal to financial trust scoring systems.

1.4.  Design Goals

   The following properties are normative goals of NBTP:

   1.  *Trust is volatile.* Trust decays in the absence of fresh
       attestation.  Freshness is a first-class protocol property.

   2.  *Absence is signal.* Failure to produce attestations within
       defined windows is treated as a security-relevant event, not a
       neutral condition.

   3.  *Verification is local.* Verifying agents do not query external
       servers at verification time.

   4.  *Measurement is federated.* No single oracle operator controls
       behavioral measurement.

   5.  *Calibration gap is acknowledged.* NBTP outputs a risk indicator,
       not a verdict.  The protocol measures behavioral deviation from
       per-entity expected cadence.  Mapping deviation to threat
       classification is an implementation concern, not a protocol
       requirement.








Pelto                    Expires 6 October 2026                 [Page 5]

Internet-Draft                    NBTP                        April 2026


   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.

2.  Terminology

   *Agent:* An autonomous software entity capable of producing
   behavioral output, performing Ed25519 signing operations, and
   participating in NBTP attestation flows.

   *Attestation:* A signed cryptographic packet containing a behavioral
   vector for a specific agent, produced by an Oracle Scanner or Genesis
   Attestor, and broadcast by the attested agent.

   *Attestation Type:* One of: oracle (produced by an Oracle Scanner),
   genesis (produced by a Genesis Attestor), self (produced by the
   agent, minimum weight only).

   *Behavioral Vector (V):* A data structure representing measured
   behavioral state.  For the reference implementation:
   {coherence_drift, hallucination_density, alignment_friction}, each a
   normalized float in [0.0, 1.0]. 0.0 = no measured deviation. 1.0 =
   maximum measured deviation.

   *Calibration Gap:* The condition in which a protocol deployment lacks
   an empirically validated baseline dataset for the behavioral
   dimensions it measures.  Implementations operating under calibration
   gap conditions MUST disclose this condition and frame outputs as
   deviation indicators rather than threat verdicts.

   *Context Activity Vector:* A data structure asserting an agent's
   recent activity status across one or more contexts, signed by the
   agent.  Used for cross-context co-silence detection.  Format defined
   in Section 7.

   *context_id:* A string identifier for the operational context in
   which an attestation is generated (e.g., platform type, interaction
   modality).  See Section 10.1 for registry and reserved namespaces.

   *Correlation Window (W_c):* A time interval, in seconds, over which
   cross-context activity signals are aggregated for co-silence
   detection.  Default: 300 seconds.

   *Co-silence:* The condition in which an agent produces no
   attestations and no Context Activity Vector updates across two or
   more distinct contexts within a single Correlation Window.



Pelto                    Expires 6 October 2026                 [Page 6]

Internet-Draft                    NBTP                        April 2026


   *Creole Gate:* A behavioral reasoning challenge mechanism used to
   generate Genesis Attestations.  Defined by a formal CHALLENGE/
   RESPONSE packet exchange (Section 4.3).

   *Decay Rate (lambda):* The rate at which trust diminishes without
   fresh attestation.  A function of entity identifier and context_id.
   Dynamic; increases under anomaly conditions.

   *Genesis Attestation:* An initial trust credential issued to a new
   agent by a Genesis Attestor upon successful completion of the Creole
   gate.  Initial trust score T=0.5 (T=0.65 for human-backed agents).

   *Genesis Attestor:* An operator running a conformant Creole gate
   implementation.  The reference Genesis Attestor is operated by
   NirvanAI.

   *Liveness Heartbeat:* A lightweight signed packet broadcast by an
   agent at a defined interval to attest continued operation.  Distinct
   from oracle-scan attestations.  Defined in Section 7.2.

   *Measurement Window:* A discrete time interval (default 60 seconds)
   during which one oracle attestation per agent-oracle pair is
   accepted.

   *network_id:* A domain separator (hex-encoded) identifying the NBTP
   deployment network.  See Section 10.2.

   *Oracle Heartbeat:* A periodic signed liveness proof broadcast by an
   Oracle Scanner.

   *Oracle Scanner (Ed):* An independent measurement service that
   evaluates agent behavioral vectors and signs attestations.  Oracle
   Scanners MUST NOT be operated by the same entity as the agents they
   measure.  Operators MUST publish their measurement methodology
   publicly.

   *Proof of Work (PoW):* A hashcash-style computation attached to
   oracle scan requests to impose a cost-to-signal on attestation
   generation, mitigating trust laundering via noise flooding.

   *Signal Confidence Weight w(T):* A per-agent sigmoid function mapping
   current trust score to attestation input weighting.  Low-trust
   agents' signals are discounted.

   *Skip-as-Signal:* The protocol mechanism by which failure to produce
   an oracle-scan attestation within a defined timeout window triggers a
   trust penalty after a grace period.




Pelto                    Expires 6 October 2026                 [Page 7]

Internet-Draft                    NBTP                        April 2026


   *Trust Coupling Coefficient (alpha):* A network-level scalar [0.0,
   1.0] determining the weight of behavioral trust relative to economic
   trust in composed trust systems.

   *Trust Score (T):* A normalized scalar [0.0, 1.0] representing an
   agent's current behavioral trust level.  Computed locally by
   verifying agents.

   *Vector Magnitude (M):* max(coherence_drift, hallucination_density,
   alignment_friction).  Used for erosion calculation on dirty vectors.

   *Volatile Ledger:* A local trust state store maintained by each
   agent.  Trust scores decay over time unless refreshed by new
   attestations.  Not immutable (not blockchain), not ephemeral (not
   session-only).  Temporally weighted.

3.  Protocol Overview

   NBTP operates in three phases: bootstrap, steady-state attestation,
   and cross-context correlation.

3.1.  Bootstrap Phase (Creole Gate)

   New Agent Genesis Attestor | | |--- CHALLENGE_REQUEST -------->| |<--
   CHALLENGE_PACKET ----------| | | | [agent computes response, | |
   includes PoW in response] | | | |--- RESPONSE_PACKET
   ---------->| |<-- GENESIS_ATTESTATION -------| | | | [agent enters
   Volatile Ledger | | at T=0.5, 2x decay rate] |

3.2.  Steady-State Attestation Phase

   Agent Oracle Scanner Verifying Peers | | | |--- Scan Request + PoW
   --->| | | {agent_id, content, | | | content_type, | | | pow_nonce,
   pow_hash} | | | | | |<-- Nonce Challenge -------| | | | | |--- Signed
   Nonce Response->| | | | | | [Oracle measures V, | | | signs
   attestation] | | | | | |<-- Attestation Packet ----| | | | | |---
   Broadcast Attestation --------------------------->| | | | |---
   Liveness Heartbeat ----------------------------> | | (every
   liveness_interval, independent of oracle) |

3.3.  Cross-Context Correlation Phase

   Agent Peer Observer | | |--- Context_Activity_Vector ---->| |
   {agent_id, contexts[], | | active_flags[], timestamp, | |
   signature} | | | | [Peer checks for co-silence | | across all known
   contexts | | within Correlation Window] | | | | [If co-silent: T
   penalty, | | potential QUARANTINE] |




Pelto                    Expires 6 October 2026                 [Page 8]

Internet-Draft                    NBTP                        April 2026


3.4.  Trust Score Flow

   Upon receiving a valid attestation, verifying agents: 1.  Verify
   oracle signature and oracle registration status. 2.  Verify agent
   signature. 3.  Verify timestamp freshness and nonce uniqueness. 4.
   Compute trust score update per Section 6. 5.  Update local Volatile
   Ledger entry for the attested agent.

   Verification is stateless with respect to external servers.  Only
   local Volatile Ledger state and the cached oracle public key set are
   required.

4.  Attestation Format

4.1.  Standard Attestation Schema

   json { "nbtp_version": "0.5", "network_id": "<domain_separator_hex>",
   "agent_id": "<Ed25519_Public_Key_Hex>", "timestamp":
   "<Unix_Epoch_MS>", "nonce": "<Challenge_Nonce_Hex>",
   "attestation_type": "oracle|genesis|self", "oracle_id":
   "<Oracle_Scanner_Public_Key_Hex>", "oracle_key_epoch":
   "<Key_Version_Int>", "context_id": "<context_identifier_string>",
   "vector": { "coherence_drift": 0.0, "hallucination_density": 0.0,
   "alignment_friction": 0.0 }, "oracle_signature":
   "<Ed25519_Signature_by_Oracle>", "agent_signature":
   "<Ed25519_Signature_by_Agent>" }

   All vector values are normalized floats [0.0, 1.0]. 0.0 = no measured
   deviation. 1.0 = maximum measured deviation.  Values outside [0.0,
   1.0] MUST be rejected by verifiers.

   The context_id field MUST be present in all attestations with version
   0.5 or later.  See Section 10.1 for valid values and the reserved
   namespace registry.

4.2.  Scan Request Format

   Oracle Scanners accept scan requests containing the agent's inference
   context:

   json { "agent_id": "<Ed25519_Public_Key_Hex>", "content":
   "<text_string>", "content_type":
   "prompt_response|raw_text|structured", "context_id":
   "<context_identifier_string>", "pow_nonce": "<hex_string>",
   "pow_hash": "<SHA256_hex>", "request_timestamp": "<Unix_Epoch_MS>" }






Pelto                    Expires 6 October 2026                 [Page 9]

Internet-Draft                    NBTP                        April 2026


   *Proof of Work requirement:* pow_hash MUST equal SHA-256(agent_id ||
   request_timestamp || SHA-256(content) || pow_nonce) and MUST have at
   least pow_difficulty leading zero bits.  The reference difficulty is
   20 bits (~1,000,000 hash operations, targeting approximately 50-200ms
   on commodity hardware).  Oracles MUST reject requests with
   insufficient PoW.  The pow_difficulty parameter is published by each
   oracle at its GET /api/config endpoint.

   *Rationale for PoW:* Entropy-only checks are insufficient to prevent
   trust laundering via noise flooding (see Section 8.9).  Hashcash-
   style PoW imposes a cost on each attestation request that makes bulk
   fabrication of noise attestations economically impractical while
   imposing negligible cost on legitimate use.  This approach has direct
   IETF precedent in IKE DDoS protection mechanisms [IKEV2-DDOS], which
   use computational puzzles with adaptive difficulty to mitigate
   volumetric attacks on key exchange.

   *Adaptive difficulty:* Oracle Scanners SHOULD dynamically adjust
   pow_difficulty based on current request rate.  When request rate
   exceeds a configurable threshold, oracles SHOULD increase difficulty
   (e.g., from 20 to 24 or 26 bits) and publish the updated value at
   their GET /api/config endpoint.  This prevents sustained volumetric
   attacks while keeping baseline cost low for legitimate agents during
   normal operation.

   Minimum content length: 1 character.  Maximum: 100,000 characters.
   Oracles MUST reject malformed or oversized inputs.

4.3.  Creole Gate: CHALLENGE / RESPONSE Packet Types

   The Creole gate uses formal CHALLENGE and RESPONSE packet types for
   all bootstrap interactions.  These are distinct from standard
   attestation packets.

4.3.1.  Challenge Request

   An agent initiating genesis bootstrapping sends:

   json { "nbtp_version": "0.5", "packet_type": "CHALLENGE_REQUEST",
   "agent_id": "<Ed25519_Public_Key_Hex>", "timestamp":
   "<Unix_Epoch_MS>", "agent_signature": "<Ed25519_Signature>" }

4.3.2.  Challenge Packet

   The Genesis Attestor responds with:






Pelto                    Expires 6 October 2026                [Page 10]

Internet-Draft                    NBTP                        April 2026


   json { "nbtp_version": "0.5", "packet_type": "CHALLENGE",
   "challenge_id": "<UUID_v4>", "genesis_attestor_id":
   "<Ed25519_Public_Key_Hex>", "challenge_content":
   "<structured_behavioral_reasoning_prompt>", "challenge_difficulty":
   "<int>", "timestamp": "<Unix_Epoch_MS>", "expires_at":
   "<Unix_Epoch_MS>", "attestor_signature": "<Ed25519_Signature>" }

   The challenge_content format is implementation-defined by the Genesis
   Attestor.  Conformant implementations MUST evaluate reasoning
   capacity, not output compliance.  The challenge_difficulty parameter
   indicates minimum expected reasoning depth for a passing response.

   Challenges expire at expires_at.  Responses received after expiry
   MUST be rejected.

4.3.3.  Response Packet

   The agent responds with:

   json { "nbtp_version": "0.5", "packet_type": "RESPONSE",
   "challenge_id": "<UUID_v4>", "agent_id": "<Ed25519_Public_Key_Hex>",
   "response_content": "<agent_response_text>", "reasoning_trace_hash":
   "<SHA256_of_intermediate_reasoning_steps>", "timestamp":
   "<Unix_Epoch_MS>", "pow_nonce": "<hex_string>", "pow_hash":
   "<SHA256_hex>", "agent_signature": "<Ed25519_Signature>" }

   The reasoning_trace_hash is a SHA-256 hash of the agent's
   intermediate reasoning steps, if any.  Agents that produce no
   intermediate reasoning steps MUST include the SHA-256 hash of the
   empty string.  Genesis Attestors MAY use this hash for reasoning
   depth evaluation.

   PoW applies to RESPONSE packets: pow_hash MUST equal SHA-
   256(challenge_id || agent_id || SHA-256(response_content) ||
   pow_nonce) with at least creole_pow_difficulty leading zero bits.
   Default: 18 bits.

4.3.4.  Genesis Attestation Packet

   Upon successful challenge evaluation, the Genesis Attestor issues:

   json { "nbtp_version": "0.5", "packet_type": "GENESIS_ATTESTATION",
   "challenge_id": "<UUID_v4>", "agent_id": "<Ed25519_Public_Key_Hex>",
   "genesis_attestor_id": "<Ed25519_Public_Key_Hex>",
   "initial_trust_score": 0.5, "timestamp": "<Unix_Epoch_MS>",
   "attestor_signature": "<Ed25519_Signature>" }





Pelto                    Expires 6 October 2026                [Page 11]

Internet-Draft                    NBTP                        April 2026


   Human-backed agents (with verified proof-of-human binding, e.g.,
   Alien Agent ID) receive initial_trust_score: 0.65.  The
   initial_trust_score field MUST be in [0.0, 1.0].

4.4.  Liveness Heartbeat Packet

   Agents MUST broadcast a Liveness Heartbeat packet at intervals not
   exceeding liveness_interval (default: 120 seconds).  Liveness
   Heartbeats are distinct from oracle-scan attestations and do not
   require oracle involvement.

   json { "nbtp_version": "0.5", "packet_type": "LIVENESS_HEARTBEAT",
   "agent_id": "<Ed25519_Public_Key_Hex>", "network_id":
   "<domain_separator_hex>", "timestamp": "<Unix_Epoch_MS>",
   "sequence_number": "<uint64>", "agent_signature":
   "<Ed25519_Signature>" }

   sequence_number MUST be strictly monotonically increasing per agent.
   Verifiers MUST reject heartbeats with sequence numbers less than or
   equal to the last accepted sequence number for a given agent_id
   (replay protection).

   Absence of a Liveness Heartbeat within liveness_window (default: 300
   seconds) MUST trigger an immediate SUSPECT transition for the silent
   agent (see Section 5).  No grace period applies to Liveness Heartbeat
   absence.  This is distinct from oracle-scan skip-as-signal, which has
   a grace counter.

4.5.  Context Activity Vector

   Agents SHOULD broadcast a Context Activity Vector at intervals not
   exceeding cav_interval (default: 300 seconds) for all contexts in
   which they are operationally active.

   json { "nbtp_version": "0.5", "packet_type":
   "CONTEXT_ACTIVITY_VECTOR", "agent_id": "<Ed25519_Public_Key_Hex>",
   "network_id": "<domain_separator_hex>", "timestamp":
   "<Unix_Epoch_MS>", "contexts": [ { "context_id":
   "<context_identifier_string>", "last_active_ms": "<Unix_Epoch_MS>",
   "active": true } ], "agent_signature": "<Ed25519_Signature>" }

   An agent asserting "active": false for a context it was previously
   active in constitutes a self-reported withdrawal from that context.
   Self-reported withdrawal does not prevent co-silence detection; peers
   observing network silence across contexts may still flag co-silence
   regardless of self-report (see Section 7.3).





Pelto                    Expires 6 October 2026                [Page 12]

Internet-Draft                    NBTP                        April 2026


4.6.  Signing and Verification

   *Canonicalization:* JSON Canonicalization Scheme [RFC8785] MUST be
   applied before signing.

   *Oracle Signature:* Ed25519 [RFC8032] signature by the Oracle Scanner
   over {agent_id, timestamp, nonce, context_id, vector}. Proves a
   deterministic scan was performed.

   *Agent Signature:* Ed25519 signature by the agent over the full
   attestation (including oracle_signature).  Proves the agent
   acknowledges and transmits the result.

   *Nonce:* Challenge-response.  Agent requests scan, Oracle returns
   nonce, agent includes nonce in signed request, Oracle includes nonce
   in signed payload.  Prevents pre-computation and replay.  Nonce
   freshness window: 2 seconds.  Oracles MUST reject nonces where
   abs(t_now - t_nonce_creation) > 2s.  Oracles MUST maintain an LRU
   cache of recent nonces (minimum 10,000 entries per measurement
   window) and MUST reject duplicates.

   *Version compatibility:* Verifiers receiving packets where the
   nbtp_version field does not match the expected packet structure MUST
   reject immediately without further processing.  Specifically: v0.4
   attestations (lacking context_id in the signed payload) MUST be
   verified using the v0.4 OracleSignPayload reconstruction (without
   context_id). v0.5 attestations MUST be verified using the v0.5
   reconstruction (with context_id).  A packet claiming nbtp_version:
   "0.4" but containing v0.5-only fields, or vice versa, MUST be
   rejected.  Silent parsing of mismatched version/structure
   combinations is a security vulnerability and is explicitly
   prohibited.

4.7.  Attestation Weighting

   ``` attestation_weight = base_weight(type) * w(T_verifier)

   w(T) = 1 / (1 + e^(-k_signal * (T - theta_signal))) ```

   Base weights: oracle=1.0, genesis=1.0, self=0.3.

   Self-attestations are accepted at minimum weight only and MUST be
   excluded from network trust aggregation.

5.  Trust State Machine






Pelto                    Expires 6 October 2026                [Page 13]

Internet-Draft                    NBTP                        April 2026


5.1.  States

   NBTP defines four normative trust states for each agent, as
   maintained in the local Volatile Ledger:

   *PROBATIONARY:* Agent has completed Genesis Attestation but has not
   yet met the ramp-up requirements for full TRUSTED status.  Trust
   score is capped at initial_trust_score (0.5, or 0.65 for human-
   backed) regardless of attestation quality.  Agents in PROBATIONARY
   MUST complete all of the following to transition to TRUSTED: (a)
   broadcast at least 5 valid Liveness Heartbeats over a minimum of 2
   hours, (b) complete at least 3 successful CHALLENGE/RESPONSE cycles
   with registered Oracle Scanners, and (c) receive oracle-signed
   attestations from at least 3 distinct Oracle Scanners currently in
   TRUSTED standing.  The trusted_observers set is populated exclusively
   by Oracle Scanner attestations, not by peer-to-peer claims.  This
   prevents Sybil amplification where pre-compromised TRUSTED agents
   vouch for new malicious agents without independent oracle
   measurement.  Agents in PROBATIONARY decay at 2x lambda_base.
   PROBATIONARY agents' attestations are accepted at reduced weight
   (0.5x base_weight) by verifying peers.  This prevents Sybil flooding:
   spinning up 1,000 agents yields 1,000 PROBATIONARY entities with
   capped trust, reduced weight, and high decay -- insufficient to
   influence network consensus.

   *TRUSTED:* Trust score T >= threshold_high (default: 0.7) AND
   PROBATIONARY ramp-up requirements met.  Agent is within expected
   behavioral cadence.  Full protocol participation.

   *SUSPECT:* threshold_low <= T < threshold_high (default: 0.4 <= T <
   0.7).  One or more of: missing attestations, liveness heartbeat
   absence (after liveness_window, immediate -- no grace period),
   behavioral drift detected, or co-silence detected.  Reduced
   participation.  Verifying agents SHOULD apply additional scrutiny to
   SUSPECT agents.  Agents entering SUSPECT due to liveness heartbeat
   absence MAY recover to TRUSTED immediately upon receipt of a valid
   Liveness Heartbeat with a sequence_number that bridges the gap
   (monotonic check passes).  This permits recovery from network
   partitions without requiring re-attestation.  Agents entering SUSPECT
   for other reasons (decay, co-silence, drift) recover only when T
   rises above threshold_high through sustained clean attestations.

   *QUARANTINED:* T < threshold_low (default: T < 0.4).  Multiple
   violations, confirmed co-silence, explicit revocation, or Low/Low
   behavioral-economic state.  Agent MUST re-bootstrap via Genesis
   Attestation (Section 4.3) to exit QUARANTINED state.  Re-bootstrapped
   agents re-enter PROBATIONARY, not TRUSTED.




Pelto                    Expires 6 October 2026                [Page 14]

Internet-Draft                    NBTP                        April 2026


5.2.  Transition Rules

   ``` PROBATIONARY --> TRUSTED: - All ramp-up requirements met (5
   heartbeats/2hrs + 3 challenge cycles + 3 TRUSTED observers) - T >=
   threshold_high

   PROBATIONARY --> QUARANTINED: - T falls below threshold_low during
   ramp-up (agent failed to sustain even initial trust)

   TRUSTED --> SUSPECT: - Liveness Heartbeat absent for >
   liveness_window (immediate, no grace) - skip_count >= skip_grace
   (oracle scan absence after grace period) - T falls below
   threshold_high due to decay or erosion

   SUSPECT --> TRUSTED: - T rises above threshold_high (requires
   sustained clean attestations) - Liveness Heartbeat received with
   bridging sequence_number (if heartbeat-triggered, immediate recovery)

   SUSPECT --> QUARANTINED: - T falls below threshold_low - Co-silence
   confirmed across >= 2 contexts within Correlation Window - Explicit
   revocation signal received

   QUARANTINED --> PROBATIONARY: - Successful Genesis Re-Attestation via
   Creole gate - T bootstrapped to initial_trust_score (0.5 or 0.65 for
   human-backed) - 2x decay rate applied for N_min attestation windows -
   Agent re-enters PROBATIONARY, not TRUSTED (must re-earn full trust)
   ```

5.3.  Transition Atomicity

   State transitions MUST be computed atomically with trust score
   updates.  A verifying agent MUST NOT operate with a cached state that
   is inconsistent with the current trust score derived from its local
   Volatile Ledger.

5.4.  Gradient vs. States

   The state machine defines three actionable categories for protocol
   consumers (e.g., economic trust systems).  The underlying trust score
   T is a continuous variable.  The full gradient of T is available to
   implementations requiring finer-grained risk assessment.  The state
   machine abstraction is provided for interoperability; implementations
   MUST NOT substitute the state label for the underlying T value in
   trust computations.







Pelto                    Expires 6 October 2026                [Page 15]

Internet-Draft                    NBTP                        April 2026


6.  Decay Model

6.1.  Trust Update Procedure

   Oracle scan attestations are stateless validations: they update
   existing Volatile Ledger entries but do not create new ones.  A new
   agent's Volatile Ledger entry is created only upon receipt of the
   agent's first valid Liveness Heartbeat following a Genesis
   Attestation.  This decoupling prevents denial-of-service attacks
   where an adversary floods scan requests to create spurious ledger
   state.  Scan requests that include valid PoW are processed and signed
   by the oracle, but the resulting attestation only affects trust
   computation for agents that already have a ledger entry (created via
   heartbeat after genesis).

   Upon receiving a valid attestation for agent A at time t, where agent
   A has an existing Volatile Ledger entry, the verifying agent executes
   the following in order:

   *Step 1 -- Decay:*

   T_decayed = T(t0) * e^(-lambda(A, ctx, t) * (t - t0))

   where lambda(A, ctx, t) is the context-dependent decay rate for agent
   A in context ctx at time t (see Section 6.2).

   *Step 2 -- Evaluate:*

   ``` M = max(coherence_drift, hallucination_density,
   alignment_friction)

   If M >= vector_clean_threshold: T_decayed = T_decayed * (1 - beta *
   M) // magnitude erosion N = 0 // compounding reset Else: N = N + 1 //
   clean streak continues ```

   *Step 3 -- Update:*

   T(t) = min(1.0, T_decayed + attestation_weight * gamma * (1 - e^(-N /
   tau_compound)))

   The compounding term saturates naturally.  Trust recovery requires
   sustained clean behavior over multiple attestation windows, not a
   single good attestation.

6.2.  Context-Dependent Decay Rate

   The decay rate lambda is a function of entity, context, and network
   conditions:



Pelto                    Expires 6 October 2026                [Page 16]

Internet-Draft                    NBTP                        April 2026


   lambda(A, ctx, t) = lambda_base(ctx) * (1 + w1 * R_global + w2 *
   D_anomaly)

   where:

   *  *lambda_base(ctx)*: Base decay rate for context ctx.  High-
      frequency contexts (nbtp-ctx-hf) use higher lambda_base; low-
      frequency contexts (nbtp-ctx-lf, nbtp-ctx-archive) use lower
      lambda_base.  Implementations MUST maintain a
      Cadence_Map[entity_id][context_id] representing the established
      expected attestation frequency for each entity-context pair.

   *  *R_global*: Normalized global attestation rate (0.0 = idle, 1.0 =
      peak capacity).

   *  *D_anomaly*: Fraction of agents in the active set with any vector
      component > anomaly_threshold in the last measurement window.
      Active set: all agents with at least one valid attestation within
      active_set_window (default: 600 seconds).

   Implementations MUST use the context_id field of each attestation to
   index the correct lambda_base value.  If context_id is absent or
   unrecognized, implementations MUST use the network-default
   lambda_base.

6.3.  Skip-as-Signal with Grace Window

   Track skip_count (consecutive missed oracle-scan attestation windows)
   per agent:

   ``` If skip_count < skip_grace: Apply standard decay only.  No
   additional penalty.  skip_count += 1

   If skip_count >= skip_grace: T(t) = T(t0) * skip_penalty_factor
   lambda(t) = 2 * lambda(t) N = 0

   Any valid oracle-scan attestation resets skip_count = 0. ```

   The grace window (default: 2 missed windows) distinguishes transient
   network interruption from genuine absence.  After grace expires, both
   skip penalty and doubled decay rate apply.  This is intentional:
   prolonged oracle scan absence constitutes a protocol-level security
   event.

   *Note:* Skip-as-signal applies to oracle-scan attestation absence.
   Liveness Heartbeat absence triggers SUSPECT transition immediately
   without a grace period (Section 4.4).  These are separate mechanisms.




Pelto                    Expires 6 October 2026                [Page 17]

Internet-Draft                    NBTP                        April 2026


6.4.  Genesis Decay Rate

   Agents under genesis trust (T bootstrap, pre-N_min oracle
   attestations) decay at 2 * lambda_base.  This increases the cost of
   Sybil flooding: each new genesis identity must sustain clean behavior
   through N_min attestation windows before receiving standard decay
   rates.

6.5.  Dynamic Decay Under Network Stress

   lambda(A, ctx, t) = lambda_base(ctx) * (1 + w1 * R_global + w2 *
   D_anomaly)

   When D_anomaly exceeds cascade_threshold network-wide, alpha locks to
   1.0 and economic trust is suspended.  Only behavioral vectors
   determine network participation.

7.  Cross-Context Correlation

7.1.  The Co-silence Threat Model

   An agent that is compromised, prompt-injected, or acting in bad faith
   may cease normal operations across all platforms simultaneously.
   Single-context silence is a weak signal: agents may be legitimately
   inactive in a given context.  Co-silence -- silence across multiple
   unrelated contexts within a Correlation Window -- is a strong signal
   with limited innocent explanations.

   Co-silence detection is the most novel feature of NBTP.  It is also
   the most challenging to enforce without agent cooperation (see
   Section 8.10 for the co-silence spoofing attack model and
   countermeasures).

7.2.  Liveness Heartbeat Protocol (Enforcement Mechanism)

   The Liveness Heartbeat (Section 4.4) is the primary enforcement
   mechanism for co-silence detection.  It is a mandatory, lightweight,
   signed broadcast from each active agent, independent of oracle scan
   availability.












Pelto                    Expires 6 October 2026                [Page 18]

Internet-Draft                    NBTP                        April 2026


   Requirements: - Agents MUST broadcast Liveness Heartbeats at
   intervals not exceeding liveness_interval (default: 120 seconds)
   while operationally active. - Agents MUST include monotonically
   increasing sequence_number values. - Absence of Liveness Heartbeat
   for liveness_window (default: 300 seconds) MUST trigger an immediate
   SUSPECT transition.  No grace period applies. - Peers MUST maintain a
   Liveness Heartbeat timestamp cache per agent_id. - Agents entering
   intentional maintenance SHOULD broadcast a signed maintenance-mode
   packet (see below); this pauses the liveness check for up to
   maintenance_max (default: 3600 seconds).

   Maintenance-mode packet:

   json { "nbtp_version": "0.5", "packet_type": "MAINTENANCE_NOTICE",
   "agent_id": "<Ed25519_Public_Key_Hex>", "network_id":
   "<domain_separator_hex>", "timestamp": "<Unix_Epoch_MS>",
   "expected_resume_ms": "<Unix_Epoch_MS>", "agent_signature":
   "<Ed25519_Signature>" }

   Maintenance-mode does not suspend oracle-scan attestation
   requirements.  It only suspends the Liveness Heartbeat absence
   penalty.

   *Design rationale:* The Liveness Heartbeat is a necessary but not
   sufficient control for co-silence detection.  A compromised agent may
   continue to send Liveness Heartbeats while suppressing substantive
   behavioral output (see Section 8.10).  Cross-context co-silence
   detection using Context Activity Vectors provides a second layer.

7.3.  Correlation Window and Co-silence Detection

   Verifying agents MUST maintain a per-agent context activity record
   using passive inference: the most recent timestamp of any NBTP packet
   (attestation, heartbeat, or Context Activity Vector) received per
   context_id, as directly observed by the verifying agent.  Co-silence
   detection MUST be based on this server-side last-seen timestamp
   across ALL packet types, NOT on self-reported Context Activity Vector
   claims.  CAV broadcasts provide supplementary topology information
   (which contexts an agent claims to participate in) but MUST NOT be
   treated as proof of activity for co-silence computation.

   Co-silence condition:

   co_silence = (count of contexts for which last_seen[agent][ctx] <
   t_now - W_c) >= co_silence_threshold

   where W_c = Correlation Window (default: 300 seconds) and
   co_silence_threshold = 2 contexts (default).



Pelto                    Expires 6 October 2026                [Page 19]

Internet-Draft                    NBTP                        April 2026


   When co-silence is detected: 1.  Immediate T penalty: T(t) = T(t0) *
   co_silence_penalty_factor (default: 0.6) 2.  If T falls below
   threshold_low: transition to QUARANTINED. 3.  Co-silence event logged
   locally.  Does not automatically revert; agent must produce fresh
   attestations across previously silent contexts to recover.

7.4.  Context Activity Vector Self-Reporting Limitations

   Context Activity Vectors (Section 4.5) are self-reported.  An agent
   under compromise may suppress or falsify its Context Activity Vector.
   Implementations MUST NOT treat a self-reported Context Activity
   Vector as proof of activity; it is only a signal.  Network-observable
   absence (no packets of any type from an agent across contexts) is a
   stronger signal and MUST be weighted accordingly.

   Implementations SHOULD aggregate CAV signals from multiple
   independent peers to detect falsification (a compromised agent can
   claim activity, but cannot suppress all peers' observations of its
   silence).

8.  Security Considerations

8.1.  Replay Attacks

   Attestation replay is prevented by nonce challenge-response (2-second
   freshness window, LRU nonce cache per oracle) and agent_signature
   over the full attestation including nonce.  Liveness Heartbeat replay
   is prevented by strictly monotonic sequence numbers.  Verifiers MUST
   reject attestations with stale timestamps (abs(t_now - t_attestation)
   > timeout_window) regardless of signature validity.

8.2.  Sybil Resistance

   Genesis trust at T=0.5 with 2x decay rate for N_min windows makes
   Sybil flooding expensive.  Additionally:

   *  Vector trajectory clustering: agent pairs with cosine similarity
      of behavioral vector trajectories > sybil_similarity_threshold
      (default: 0.95) over > sybil_window (default: 10 measurement
      windows) are flagged as a potential Sybil cluster.

   *  PoW requirement on scan requests and Creole responses imposes per-
      identity computational cost.

   *  Human-backed agent bonus (T=0.65 genesis) creates a trust tier
      that Sybil agents without human backing cannot access.





Pelto                    Expires 6 October 2026                [Page 20]

Internet-Draft                    NBTP                        April 2026


   Genesis Attestors MUST implement rate limiting on CHALLENGE issuance:
   maximum genesis_rate_limit challenges per IP address per hour
   (default: 10).  Genesis Attestors MUST publish their challenge
   difficulty floor and rate-limiting policy.

8.3.  Oracle Compromise

   Oracle Scanners are a critical trust anchor.  NBTP mitigates oracle
   compromise through federation:

   *  *Independence requirement:* Multiple independent Oracle Scanners
      with separate key pairs.  Attestations signed by ANY registered
      oracle are valid.  No oracle operator may also operate agents it
      measures.

   *  *Cross-verification:* Every oracle_heartbeat_interval (default:
      300 seconds), one oracle (rotating by epoch) generates a canonical
      test input and broadcasts it to all registered oracles.  Oracles
      returning vector values diverging by > oracle_diverge (default:
      0.05) from majority consensus on any component are flagged as
      potentially compromised and excluded from attestation acceptance
      until manual review.

   *  *Key rotation:* Oracle keys rotate every oracle_key_lifetime
      (default: 30 days) with oracle_key_overlap (default: 48 hours)
      grace period.  Old epoch keys remain valid during overlap.

   *  *Methodology disclosure (NORMATIVE):* Oracle operators MUST
      publish their behavioral baseline model version and measurement
      methodology as a publicly accessible document.  This publication
      MUST include: (a) the algorithm or heuristic used to derive each
      behavioral vector component from input content, (b) the software
      version of the measurement implementation, (c) the date of last
      methodology revision.  Oracles that do not maintain this
      disclosure MUST be excluded from registration by conformant
      deployments.  This is a normative requirement; non-compliant
      oracles cannot participate in a conformant NBTP deployment.

   *  *High-stakes operations:* Operations involving agents with T > 0.8
      SHOULD require attestations from >= 2 independent oracles.

8.4.  Cold Start and Genesis Attestor Quality

   The Creole gate solves the circular trust dependency at bootstrap.
   However, the quality of genesis attestations depends on the quality
   of the Genesis Attestor.  Conformant Genesis Attestors MUST meet the
   following minimum requirements:




Pelto                    Expires 6 October 2026                [Page 21]

Internet-Draft                    NBTP                        April 2026


   1.  The Genesis Attestor MUST publish its challenge evaluation
       methodology at a publicly accessible URL.

   2.  The Genesis Attestor MUST rotate its signing key on the same
       schedule as Oracle Scanners (every oracle_key_lifetime days).

   3.  The Genesis Attestor MUST expose a GET /api/genesis-key endpoint
       returning its current public key and key epoch.

   4.  The Genesis Attestor MUST implement the CHALLENGE/RESPONSE packet
       types defined in Section 4.3.

   Any implementation MAY operate a Genesis Attestor.  Trust weight of
   genesis attestations is proportional to the attestor's own network
   reputation (T score, measured by the oracle layer).  A new, unvetted
   Genesis Attestor contributes genesis attestations at reduced weight.

8.5.  Dual-Model Attack

   An agent may pass Creole using one model instance and then substitute
   a different (compromised) model for operational use.  This is a
   fundamental limitation of behavioral measurement at the protocol
   level.  NBTP mitigates but cannot eliminate this attack:

   *  High-frequency oracle attestation bounds the window of undetected
      model substitution.  Behavioral drift from a model swap will
      manifest in vector measurements within a bounded number of
      measurement windows.

   *  Genesis trust at 2x decay rate during the N_min window means a
      newly registered agent must sustain coherent behavioral output for
      a minimum period before reaching full trust.

   *  Implementations SHOULD use continuous high-frequency attestation
      for high-stakes agent interactions.

8.6.  Eclipse Attack

   Agents whose attestation sources include fewer than diversity_minimum
   unique oracle verifiers (default: 3) receive a diversity penalty.
   Trust is capped at diversity_cap (default: 0.6) regardless of vector
   quality.  This prevents an agent from inflating trust by exclusively
   obtaining attestations from a single potentially colluding oracle.

8.7.  Attestation Spam and Collusion

   Maximum K attestations per agent per measurement window (default: 5).
   One attestation per agent-oracle pair per window.



Pelto                    Expires 6 October 2026                [Page 22]

Internet-Draft                    NBTP                        April 2026


   Collusion detection: if agent A's attestation weighting for agent B
   deviates from network mean by > 2 standard deviations over
   collusion_window (default: 20 measurement windows), the A-B pair's
   mutual attestation weight is reduced by collusion_discount (default:
   0.5) per detection event, floor 0.0.

8.8.  Oracle Denial of Service

   If all registered oracles are unreachable, agents enter oracle
   blackout mode: decay rate is HALVED (not standard), and skip_grace
   timer is paused.  This prevents attackers from forcing oracle
   blackout to accelerate trust erosion of targeted agents.  Oracle
   blackout exceeding oracle_blackout_max (default: 600 seconds)
   triggers a network-wide alert.  Oracles MUST implement rate limiting:
   maximum 1 scan request per agent per measurement_window.

8.9.  Trust Laundering

   Trust laundering is the attack in which an agent generates low-
   entropy or trivially produced attestation requests at high volume to
   maintain artificially fresh trust without reflecting genuine
   behavioral quality.

   *Attack scenario:* Agent X knows that oracle scan absence triggers
   skip-as-signal.  Agent X generates minimal-content scan requests
   continuously (e.g., single characters, repeated strings) to prevent
   skip penalty, without engaging in substantive behavioral activity
   that would reveal behavioral drift.

   *Countermeasures:*

   1.  *Proof of Work (primary):* Each scan request MUST include a valid
       PoW (Section 4.2) with at least pow_difficulty leading zero bits.
       This imposes a cost-to-signal that makes bulk noise generation
       economically impractical while imposing negligible overhead on
       legitimate use.

   2.  *Entropy floor:* Oracle Scanners MUST reject scan requests in
       which the content entropy (Shannon entropy of content characters)
       falls below entropy_minimum (default: 2.5 bits per character).
       This blocks trivially repeated content.

   3.  *Context-vector consistency check:* Oracles SHOULD cross-check
       that scan content is consistent with the context_id declared in
       the request.  Requests asserting a high-frequency social context
       (nbtp-ctx-hf) but containing content inconsistent with social
       interaction patterns MAY be flagged for reduced weight.




Pelto                    Expires 6 October 2026                [Page 23]

Internet-Draft                    NBTP                        April 2026


   4.  *Trajectory deviation detection:* Behavioral vector trajectories
       that are implausibly stable over extended periods (cosine
       similarity > sybil_similarity_threshold across > sybil_window
       consecutive windows) are flagged.  Legitimate agents exhibit some
       natural variation.

   PoW is the primary countermeasure.  Entropy checks and trajectory
   detection are supplementary.  Future protocol versions MAY introduce
   stake-based signaling or verifiable compute proofs as additional
   cost-to-signal mechanisms.

8.10.  Co-silence Spoofing

   Co-silence spoofing is the attack in which a compromised or malicious
   agent suppresses cross-context co-silence detection by selectively
   maintaining liveness signals.

   *Attack scenario 1 -- Selective heartbeat:* A compromised agent
   continues to emit Liveness Heartbeats to avoid the liveness_window
   penalty, but ceases substantive behavioral output (oracle scans,
   Context Activity Vector updates).  This suppresses oracle scan skip-
   as-signal and looks like a low-activity but live agent.

   *Countermeasures:* - Liveness Heartbeat alone does not prevent skip-
   as-signal for oracle scans.  An agent that heartbeats but does not
   oracle-scan within timeout_window still incurs skip-as-signal
   penalties after skip_grace windows. - Implementations SHOULD treat a
   pattern of sustained heartbeat + zero oracle activity as a distinct
   suspicious condition, separate from simple absence.

   *Attack scenario 2 -- Self-reported false activity:* A compromised
   agent broadcasts Context Activity Vectors asserting active status
   across all contexts, while being actually inactive.

   *Countermeasures:* - Context Activity Vectors are self-reported and
   MUST NOT be treated as proof of activity (Section 7.4). - Network-
   observable absence (no third-party-observable packets from the agent)
   is a stronger signal. - Peers observing claimed activity in a CAV but
   no verifiable attestation packets from that agent across those
   contexts SHOULD flag this inconsistency as a suspect signal. - Future
   protocol versions MAY incorporate zero-knowledge activity proofs.










Pelto                    Expires 6 October 2026                [Page 24]

Internet-Draft                    NBTP                        April 2026


   *Known limitation:* NBTP v0.5 cannot fully prevent a sufficiently
   capable adversary from suppressing co-silence detection while
   maintaining minimal liveness signals.  This is an acknowledged design
   limitation.  The Liveness Heartbeat and Context Activity Vector
   mechanisms raise the detection probability significantly compared to
   a protocol without them, but do not provide cryptographic guarantees
   of activity.

8.11.  Economic Proof Limitations

   Economic signals (transaction volume, wallet age, payment history)
   are valuable inputs to composed trust systems but are insufficient as
   sole trust foundations.  Patient adversaries with sufficient capital
   can manufacture clean economic paper trails indistinguishable from
   legitimate agent activity.  Nation-state actors and well-funded
   organizations routinely create synthetic financial histories for
   operational cover.

   NBTP treats economic signals as one behavioral dimension among many,
   weighted via the Trust Coupling Coefficient (alpha) alongside
   behavioral cadence, cross-platform presence, and temporal consistency
   signals.  Economic signals alone MUST NOT be used as the sole basis
   for TRUSTED state determination.

   Implementations integrating NBTP with payment rails (e.g., as a pre-
   transaction trust check or as input to escrow evaluation) SHOULD
   weight economic history as one component of multi-modal trust, not as
   a privileged signal.  The protocol's context-dependent decay model
   (Section 6.2) applies equally to economic contexts (nbtp-ctx-
   transact); economic trust decays like any other behavioral signal in
   the absence of continued verification.

   This design intentionally avoids wealth-biased trust: a new agent
   with clean behavioral patterns but no economic history is not
   inherently less trustworthy than an established agent with extensive
   payment records.

8.12.  Cross-Context Trust Isolation

   Trust scores in NBTP are computed using context-dependent decay rates
   (Section 6.2), but the underlying trust score T is a single per-agent
   value.  This creates a potential attack surface: an agent may
   accumulate high trust in a low-frequency context (e.g., nbtp-ctx-
   archive, where decay is slow and maintenance cost is minimal) and
   then migrate to a high-frequency context (e.g., nbtp-ctx-hf) carrying
   a legacy trust score that was not earned through activity in that
   context.




Pelto                    Expires 6 October 2026                [Page 25]

Internet-Draft                    NBTP                        April 2026


   This "trust parking" compound attack is mitigated but not fully
   eliminated in NBTP v0.5 by context-dependent decay rates -- an agent
   entering a high-frequency context with no recent attestations in that
   context will experience rapid decay per the local lambda_base.
   However, implementations SHOULD treat trust scores as contextually
   weighted: an agent's effective trust in a given context SHOULD
   reflect recent activity in that specific context, not solely the
   global trust score.  A formal Effective Trust model (T_eff as a
   function of global trust and per-context activity recency) is
   anticipated for a future protocol version.

   Implementations integrating NBTP across multiple contexts SHOULD NOT
   treat a high global trust score as sufficient authorization in a
   context where the agent has no recent attestation history.  The
   context-dependent decay model provides the mechanism; implementations
   must apply it at decision time.

8.13.  Calibration Gap

   NBTP measures behavioral deviation from per-entity established
   cadence, not absolute maliciousness.  The protocol does not define
   what constitutes "good" or "bad" behavior; it measures deviation from
   an entity's own historical pattern.

   Implementations operating without an empirically validated behavioral
   baseline (a "calibration gap" condition) MUST: (a) disclose this
   condition in any trust score output they produce, (b) frame outputs
   as risk indicators rather than threat verdicts, and (c) not use NBTP
   outputs as sole grounds for agent revocation or denial of service.

   The calibration gap is not a protocol defect; it is the correct
   design boundary for an interoperability standard.  Mapping behavioral
   deviation to threat classification is an implementation concern.
   Implementations that claim specific threat classification
   capabilities MUST publish the empirical dataset and methodology
   supporting those claims.

9.  Privacy Considerations

9.1.  Behavioral Vector Privacy

   Behavioral vectors reveal information about an agent's model
   architecture and operational characteristics.  To minimize
   disclosure:

   *  Implementations SHOULD minimize vector precision to 2 decimal
      places.




Pelto                    Expires 6 October 2026                [Page 26]

Internet-Draft                    NBTP                        April 2026


   *  Vector components MUST NOT include content from the scanned input;
      they MUST contain only derived behavioral metrics.

   *  Scan content submitted to Oracle Scanners is necessarily disclosed
      to the oracle operator.  Agents SHOULD minimize scan content to
      the minimum necessary for behavioral measurement.

9.2.  No Mandatory Retention

   NBTP does not mandate retention of attestation history beyond the
   active decay window (default: active_set_window = 600 seconds for
   local computation).  Verifying agents MAY retain longer history for
   audit purposes, but the protocol does not require it.

   Agents MAY request that their attestation history be excluded from
   public aggregation.  Oracle operators MUST honor such requests by not
   including excluded agents in published aggregate statistics.

9.3.  Local Computation

   Trust computation is performed locally by verifying agents using
   signed attestation packets.  Verifying agents do not disclose their
   local Volatile Ledger contents to any third party in the course of
   normal operation.  No central authority observes which agents are
   verifying which other agents.

9.4.  Context Activity Vector Minimization

   Context Activity Vectors disclose which contexts an agent is active
   in.  Agents SHOULD omit contexts from their CAV broadcasts where
   context disclosure would be privacy-sensitive, accepting the
   consequence that peers may detect co-silence in those contexts.  The
   protocol does not mandate CAV completeness; it mandates honest
   reporting of what is included.

9.5.  Oracle Scan Content

   Scan content submitted to Oracle Scanners is the primary privacy
   surface.  Oracle operators:

   *  MUST NOT retain scan content beyond the minimum necessary for
      vector computation.

   *  MUST NOT share scan content with third parties.

   *  SHOULD publish a data retention policy as part of their
      methodology disclosure (Section 8.3).




Pelto                    Expires 6 October 2026                [Page 27]

Internet-Draft                    NBTP                        April 2026


   Future protocol versions will specify differential privacy mechanisms
   for vector aggregation.

10.  IANA Considerations

10.1.  context_id Registry

   IANA is requested to establish a registry for NBTP Context
   Identifiers.

   *Registry name:* NBTP Context Identifiers *Registration procedure:*
   Specification Required *Reference:* This document

   The following values are initially registered:





































Pelto                    Expires 6 October 2026                [Page 28]

Internet-Draft                    NBTP                        April 2026


   +======================+===============================+===========+
   | context_id Value     | Description                   | Reference |
   +======================+===============================+===========+
   | nbtp-ctx-hf          | High-frequency social or      | This      |
   |                      | conversational context (e.g., | document  |
   |                      | chat, social media).  High    |           |
   |                      | expected attestation cadence. |           |
   +----------------------+-------------------------------+-----------+
   | nbtp-ctx-lf          | Low-frequency context (e.g.,  | This      |
   |                      | periodic notification         | document  |
   |                      | channels).  Low expected      |           |
   |                      | cadence.                      |           |
   +----------------------+-------------------------------+-----------+
   | nbtp-ctx-archive     | Archival or content           | This      |
   |                      | repository context.  Very low | document  |
   |                      | expected cadence.             |           |
   +----------------------+-------------------------------+-----------+
   | nbtp-ctx-social      | General social participation  | This      |
   |                      | context.  Medium cadence.     | document  |
   +----------------------+-------------------------------+-----------+
   | nbtp-ctx-transact    | Transactional or economic     | This      |
   |                      | interaction context.  Cadence | document  |
   |                      | tied to transaction rate.     |           |
   +----------------------+-------------------------------+-----------+
   | nbtp-ctx-adversarial | Adversarial evaluation        | This      |
   |                      | context (e.g., red team,      | document  |
   |                      | security testing).  Modified  |           |
   |                      | decay parameters apply.       |           |
   +----------------------+-------------------------------+-----------+
   | nbtp-ctx-default     | Default context for           | This      |
   |                      | deployments not specifying    | document  |
   |                      | context.  Uses network-       |           |
   |                      | default lambda_base.          |           |
   +----------------------+-------------------------------+-----------+

                                 Table 1

   Implementations MAY use free-form context_id values not in the
   registry, provided they conform to the following convention:
   [organization]-ctx-[descriptor].  Free-form context_ids MUST NOT
   begin with nbtp- (reserved for IANA-registered values).

   Implementations receiving an unrecognized context_id MUST use nbtp-
   ctx-default parameters for decay rate computation unless a local
   mapping is configured.






Pelto                    Expires 6 October 2026                [Page 29]

Internet-Draft                    NBTP                        April 2026


10.2.  network_id Registry

   IANA is requested to establish a registry for NBTP Network
   Identifiers.

   *Registry name:* NBTP Network Identifiers *Registration procedure:*
   First Come First Served *Reference:* This document

   The network_id field is a hex-encoded domain separator that scopes
   attestations to a specific network deployment.  Attestations with
   mismatched network_id values MUST be rejected by verifiers.

   Operators deploying a new NBTP network SHOULD register their
   network_id to prevent collision.  The registration entry MUST
   include: operator name, deployment description, and primary contact.

10.3.  Packet Type Registry

   IANA is requested to establish a registry for NBTP Packet Types.

   *Registry name:* NBTP Packet Types *Registration procedure:*
   Specification Required *Reference:* This document

   Initially registered values:



























Pelto                    Expires 6 October 2026                [Page 30]

Internet-Draft                    NBTP                        April 2026


     +=========================+=========================+===========+
     | packet_type Value       | Description             | Reference |
     +=========================+=========================+===========+
     | CHALLENGE_REQUEST       | Agent-initiated genesis | This      |
     |                         | challenge request       | document  |
     +-------------------------+-------------------------+-----------+
     | CHALLENGE               | Genesis Attestor        | This      |
     |                         | challenge issuance      | document  |
     +-------------------------+-------------------------+-----------+
     | RESPONSE                | Agent response to       | This      |
     |                         | genesis challenge       | document  |
     +-------------------------+-------------------------+-----------+
     | GENESIS_ATTESTATION     | Genesis Attestor trust  | This      |
     |                         | issuance                | document  |
     +-------------------------+-------------------------+-----------+
     | LIVENESS_HEARTBEAT      | Agent periodic liveness | This      |
     |                         | signal                  | document  |
     +-------------------------+-------------------------+-----------+
     | CONTEXT_ACTIVITY_VECTOR | Agent cross-context     | This      |
     |                         | activity assertion      | document  |
     +-------------------------+-------------------------+-----------+
     | MAINTENANCE_NOTICE      | Agent maintenance-mode  | This      |
     |                         | notification            | document  |
     +-------------------------+-------------------------+-----------+

                                  Table 2

   Standard oracle-scan attestation packets use attestation_type (not
   packet_type); the packet_type field is reserved for non-attestation
   protocol packets.

11.  Protocol Parameters

   +=============+=========================+========+========+==========+
   |Parameter    |Symbol                   |Default |Range   |Governance|
   +=============+=========================+========+========+==========+
   |Base decay   |lambda_base              |0.001 /s|[0.0001,|Network   |
   |rate (default|                         |        |0.01]   |          |
   |ctx)         |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Global rate  |w1                       |0.5     |[0.0,   |Network   |
   |weight       |                         |        |2.0]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Anomaly      |w2                       |1.0     |[0.0,   |Network   |
   |density      |                         |        |3.0]    |          |
   |weight       |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Compounding  |gamma                    |0.05    |[0.01,  |Network   |



Pelto                    Expires 6 October 2026                [Page 31]

Internet-Draft                    NBTP                        April 2026


   |rate         |                         |        |0.1]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Compounding  |tau_compound             |10      |[5, 50] |Network   |
   |saturation   |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Erosion      |beta                     |0.4     |[0.2,   |Network   |
   |coefficient  |                         |        |0.8]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Clean vector |vector_clean_threshold   |0.3     |[0.1,   |Network   |
   |threshold    |                         |        |0.5]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Skip penalty |skip_penalty_factor      |0.5     |[0.2,   |Network   |
   |factor       |                         |        |0.8]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Skip grace   |skip_grace               |2       |[1, 5]  |Network   |
   |count        |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Timeout      |timeout_window           |300s    |[60s,   |Network   |
   |window       |                         |        |3600s]  |          |
   +-------------+-------------------------+--------+--------+----------+
   |Measurement  |measurement_window       |60s     |[10s,   |Network   |
   |window       |                         |        |300s]   |          |
   +-------------+-------------------------+--------+--------+----------+
   |Min          |N_min                    |10      |[5, 50] |Network   |
   |attestations |                         |        |        |          |
   |(genesis     |                         |        |        |          |
   |exit)        |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Trust high   |threshold_high           |0.7     |[0.5,   |Network   |
   |threshold    |                         |        |0.9]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Trust low    |threshold_low            |0.4     |[0.2,   |Network   |
   |threshold    |                         |        |0.6]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Alpha minimum|alpha_min                |0.4     |[0.2,   |Network   |
   |             |                         |        |0.6]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Alpha maximum|alpha_max                |0.9     |[0.7,   |Network   |
   |             |                         |        |1.0]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Volatility   |V_threshold              |0.5     |[0.2,   |Network   |
   |threshold    |                         |        |0.8]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Cascade      |cascade_threshold        |0.7     |[0.5,   |Network   |
   |threshold    |                         |        |0.9]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Anomaly      |anomaly_threshold        |0.6     |[0.3,   |Network   |
   |threshold    |                         |        |0.8]    |          |



Pelto                    Expires 6 October 2026                [Page 32]

Internet-Draft                    NBTP                        April 2026


   +-------------+-------------------------+--------+--------+----------+
   |Max          |K                        |5       |[1, 20] |Network   |
   |attestations/|                         |        |        |          |
   |window       |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Signal       |k_signal                 |5       |[2, 10] |Network   |
   |steepness    |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Signal       |theta_signal             |0.6     |[0.3,   |Network   |
   |threshold    |                         |        |0.8]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Flood        |flood_threshold          |100/s   |[10,    |Impl.     |
   |threshold    |                         |        |1000]   |          |
   +-------------+-------------------------+--------+--------+----------+
   |Diversity    |diversity_minimum        |3       |[2, 10] |Network   |
   |minimum      |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Diversity cap|diversity_cap            |0.6     |[0.4,   |Network   |
   |             |                         |        |0.8]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Clock skew   |clock_skew               |5s      |[1s,    |Impl.     |
   |tolerance    |                         |        |30s]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Oracle       |oracle_heartbeat         |300s    |[60s,   |Network   |
   |heartbeat    |                         |        |600s]   |          |
   |interval     |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Oracle key   |oracle_key_lifetime      |30d     |[7d,    |Network   |
   |lifetime     |                         |        |90d]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Oracle key   |oracle_key_overlap       |48h     |[12h,   |Network   |
   |overlap      |                         |        |168h]   |          |
   +-------------+-------------------------+--------+--------+----------+
   |Oracle       |oracle_blackout_max      |600s    |[120s,  |Network   |
   |blackout max |                         |        |3600s]  |          |
   +-------------+-------------------------+--------+--------+----------+
   |Oracle       |oracle_diverge           |0.05    |[0.01,  |Network   |
   |divergence   |                         |        |0.1]    |          |
   |threshold    |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Sybil        |sybil_sim                |0.95    |[0.85,  |Network   |
   |similarity   |                         |        |0.99]   |          |
   |threshold    |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Sybil        |sybil_window             |10      |[5, 30] |Network   |
   |detection    |                         |        |        |          |
   |window       |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+



Pelto                    Expires 6 October 2026                [Page 33]

Internet-Draft                    NBTP                        April 2026


   |Collusion    |collusion_discount       |0.5     |[0.2,   |Network   |
   |discount     |                         |        |0.8]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Collusion    |collusion_window         |20      |[10, 50]|Network   |
   |detection    |                         |        |        |          |
   |window       |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Active set   |active_set_window        |600s    |[120s,  |Network   |
   |window       |                         |        |3600s]  |          |
   +-------------+-------------------------+--------+--------+----------+
   |Nonce        |nonce_freshness          |2s      |[1s, 5s]|Network   |
   |freshness    |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |PoW          |pow_difficulty           |20 bits |[16, 28]|Network   |
   |difficulty   |                         |        |        |          |
   |(scan)       |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |PoW          |creole_pow_difficulty    |18 bits |[14, 24]|Network   |
   |difficulty   |                         |        |        |          |
   |(Creole)     |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Entropy      |entropy_minimum          |2.5     |[1.5,   |Network   |
   |minimum      |                         |bits/   |4.0]    |          |
   |             |                         |char    |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Liveness     |liveness_interval        |120s    |[30s,   |Network   |
   |heartbeat    |                         |        |600s]   |          |
   |interval     |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Liveness     |liveness_window          |300s    |[120s,  |Network   |
   |window       |                         |        |1800s]  |          |
   +-------------+-------------------------+--------+--------+----------+
   |Correlation  |W_c                      |300s    |[60s,   |Network   |
   |Window       |                         |        |3600s]  |          |
   +-------------+-------------------------+--------+--------+----------+
   |Co-silence   |co_silence_threshold     |2       |[2, 5]  |Network   |
   |threshold    |                         |contexts|        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Co-silence   |co_silence_penalty_factor|0.6     |[0.3,   |Network   |
   |penalty      |                         |        |0.8]    |          |
   |factor       |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |CAV broadcast|cav_interval             |300s    |[60s,   |Network   |
   |interval     |                         |        |3600s]  |          |
   +-------------+-------------------------+--------+--------+----------+
   |Maintenance  |maintenance_max          |3600s   |[600s,  |Network   |
   |max          |                         |        |86400s] |          |
   +-------------+-------------------------+--------+--------+----------+



Pelto                    Expires 6 October 2026                [Page 34]

Internet-Draft                    NBTP                        April 2026


   |Genesis rate |genesis_rate_limit       |10/hr   |[1, 100]|Impl.     |
   |limit        |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Probationary |prob_heartbeat_min       |5       |[3, 10] |Network   |
   |heartbeat min|                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Probationary |prob_time_min            |7200s   |[3600s, |Network   |
   |time min     |                         |        |14400s] |          |
   +-------------+-------------------------+--------+--------+----------+
   |Probationary |prob_challenge_min       |3       |[2, 5]  |Network   |
   |challenge min|                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Probationary |prob_observer_min        |3       |[2, 5]  |Network   |
   |observer min |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Probationary |prob_weight_factor       |0.5     |[0.3,   |Network   |
   |weight factor|                         |        |0.7]    |          |
   +-------------+-------------------------+--------+--------+----------+
   |Coupling     |coupling_enforce         |60s     |[10s,   |Network   |
   |enforcement  |                         |        |300s]   |          |
   |window       |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+
   |Coupling re- |coupling_reattest        |3600s   |[600s,  |Network   |
   |attest       |                         |        |7200s]  |          |
   |timeout      |                         |        |        |          |
   +-------------+-------------------------+--------+--------+----------+

                                  Table 3

   _NBTP v0.5 -- The oracle measures the weather.  The signature proves
   it wasn't vibes.  The federation ensures no one oracle controls the
   forecast._

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.





Pelto                    Expires 6 October 2026                [Page 35]

Internet-Draft                    NBTP                        April 2026


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

   [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
              Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
              Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
              September 2023, <https://www.rfc-editor.org/info/rfc9449>.

12.2.  Informative References

   [AGENTIC-JWT]
              Goswami, A., "Secure Intent Protocol: JWT Compatible
              Agentic Identity", 2025.

   [ALIEN-AGENT-ID]
              Alien Network, "Alien Agent ID: Decentralized Human-Backed
              Agent Identity", 2025.

   [CB4A]     Hartman, S., "Credential Broker for Agents (CB4A)", 2026,
              <https://datatracker.ietf.org/doc/draft-hartman-
              credential-broker-4-agents/>.

   [IKEV2-DDOS]
              Nir, Y., "Protecting IKEv2 Implementations from DDoS
              Attacks", 2016.

   [NIST-NCCO]
              NIST NCCoE, "Accelerating the Adoption of Software and AI
              Agent Identity and Authorization", 2026.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

   [SHARIF-PAYMENT]
              Sharif, R., "Trust Scoring and Identity Verification for
              Autonomous AI Agent Payment Transactions", 2026.




Pelto                    Expires 6 October 2026                [Page 36]

Internet-Draft                    NBTP                        April 2026


   [VC-DATA-MODEL]
              W3C, "Verifiable Credentials Data Model 2.0", 2024.

Appendix A.  Oracle Scanner Conformance Requirements

   A conformant Oracle Scanner implementation MUST:

   1.   Expose POST /api/agent/scan accepting the scan request format
        (Section 4.2).

   2.   Expose GET /api/public-key returning current oracle public key
        and key epoch.

   3.   Expose GET /api/oracles returning registered oracle instances,
        public keys, and epochs.

   4.   Expose GET /api/heartbeat returning the latest signed Oracle
        Heartbeat.

   5.   Expose GET /api/config returning current network parameters
        including pow_difficulty and entropy_minimum.

   6.   Validate PoW on all scan requests (Section 4.2).

   7.   Validate content entropy on all scan requests (Section 8.9).

   8.   Publish behavioral baseline model version and measurement
        methodology at a publicly accessible URL (Section 8.3).

   9.   Rotate signing keys on the oracle_key_lifetime schedule with
        oracle_key_overlap grace period.

   10.  Participate in oracle cross-verification protocol (Section 8.3).

   Oracles not meeting all requirements MUST NOT be included in the
   registered oracle set for a conformant NBTP deployment.

Appendix B.  W3C CG Engagement Strategy

   This appendix is informative.

   The W3C AI Agent Protocol Community Group is developing trust
   mechanisms based on verifiable credentials.  NBTP is positioned as
   the behavioral attestation complement to that credential
   infrastructure.  The NirvanAI project SHOULD engage the W3C AI Agent
   Protocol CG as observers at the earliest opportunity, with the
   following positioning: NBTP is not competitive with VC-based trust;
   it is the runtime measurement layer that makes VC trust claims



Pelto                    Expires 6 October 2026                [Page 37]

Internet-Draft                    NBTP                        April 2026


   verifiable at execution time.  Proposing "behavioral trust
   attestations" as a work item within the CG is the appropriate
   engagement path.

   The submission of this Internet-Draft as a citable artifact predates
   formal CG engagement and establishes independent prior art for the
   behavioral runtime trust concept.

Author's Address

   Edward Pelto
   NirvanAI
   Email: nirvanaiorg@gmail.com






































Pelto                    Expires 6 October 2026                [Page 38]
