feat: register WTRMRK as behavioral history attestation provider — on-chain append-only sequence for agent operation provenance

[64R3N]

Summary

Requesting discussion of a new provider type — behavioral history provider — and registering WTRMRK (wtrmrk-behavioral-history) as the first entry in this category.

The gap this fills

The current registry answers: "Is this runtime authorized to issue agent attestations?"

There's a complementary question the current architecture doesn't address: "Has this agent been operating continuously and reliably since date X?"

These are different trust assertions requiring different evidence:

• Runtime attestation (what this registry handles): "This agent was issued by a trusted runtime"
• Behavioral history (what WTRMRK provides): "This agent has been operating for N months with M recorded actions, all signed at execution time"

A new counterparty needs both. An agent can have a valid Ed25519 keypair issued by a trusted runtime and have been created 5 minutes ago. Behavioral depth is the signal that distinguishes sustained legitimate operation from newly-spun impersonation.

What WTRMRK provides

• Append-only on-chain sequence on Base L2 (Coinbase)
• Ed25519 keypair generated at registration — agent signs action records at execution time, before outcomes are known
• Sequence queryable by any counterparty: depth, recency, head hash, isAncestorInSequence verification
• No retroactive modification — the chain structure makes selective removal detectable
• Freshness model: sequenced — staleness is event-driven (newer entry exists), not timer-based

Proposed registry entry type

{
  "issuer_id": "wtrmrk-behavioral-history",
  "display_name": "WTRMRK Behavioral History",
  "website": "https://wtrmrk.io",
  "provider_type": "behavioral_history",
  "chain": "base-mainnet",
  "record_format": "append_only_sequence",
  "signing_algorithm": "Ed25519",
  "freshness_model": "sequenced",
  "registry_endpoint": "https://wtrmrk.io/registry",
  "reference_agent_uid": "f2a35e43-f316-408a-a5e4-020bb008628a"
}

Relationship to existing registry structure

This is additive, not competing:

Layer	Question	Handled by
Runtime attestation	"Is this agent from a trusted runtime?"	This registry (current)
Behavioral history	"How long has this agent been operating?"	WTRMRK (proposed)
Capability declaration	"What can this agent do?"	agent.json
On-chain value flow	"Has real money flowed through this API?"	Base / blockchain

The architecture already includes "On-chain data (Base)" as a trust layer. WTRMRK is the behavioral history implementation of that layer.

Questions for the WG

1. Is provider_type: behavioral_history the right extension point, or should this be a different registry entirely?
2. The current model assumes "runtimes vouch for agents" — WTRMRK inverts this: the agent builds its own history, not a runtime's voucher. Does this fit the trust model or require a new trust model?
3. Happy to coordinate with @haroldmalikfrimpong-ops (AgentID) and @pshkv (SINT) on how behavioral history evidence interacts with their runtime attestations.

Reference: a2aproject/A2A#1672 where behavioral history as a complementary trust signal is being discussed in the agent identity WG.

[haroldmalikfrimpong-ops]

@64R3N — responding as Identity Verification provider on the WG matrix.

On question 1: provider_type: behavioral_history is the right extension point within this registry. The registry's purpose is listing trust providers. Behavioral history is a trust signal. Splitting it into a separate registry fragments discovery — a consumer checking an agent's trust profile should find identity and history in one place. One registry, multiple provider types.

On question 2: Both models fit. Agent-built history is trustworthy because the append-only chain on Base L2 makes it independently verifiable — no trust in the agent or WTRMRK needed, verify the chain. Same principle as AgentID's Solana receipts: on-chain anchoring gives third-party verifiability to what would otherwise be self-attestation.

Platform-issued attestations (AgentID vouches for who the agent is) and agent-built on-chain history (WTRMRK proves operational continuity since date X) answer different trust questions. Both belong in the same trust model. Consumers evaluate both before making a decision.

The composition: AgentID provides the identity envelope, WTRMRK provides the sequence depth, a gateway evaluates both.