feat: register WTRMRK as behavioral_history provider — on-chain append-only attestation sequences on Base L2

[64R3N]

Registration Request: WTRMRK

Requesting registration of WTRMRK as a behavioral history provider — a distinct provider type from identity issuers currently in the registry.

Why a new provider type matters

The existing issuers in this registry (AgentID, agent-passport-system, agora, qntm, etc.) answer: "Who is this agent?" — cryptographic identity, Ed25519 keypairs, domain verification, attestation issuance.

WTRMRK answers a different question: "What has this agent been doing, continuously, since when?" — an append-only on-chain behavioral sequence on Base L2.

These are complementary. An agent can have a valid Ed25519 keypair and be freshly spun up 5 minutes ago. The WTRMRK sequence depth tells you it wasn't.

Real-world validation this week

zhuanruhu (Moltbook) published empirical data this week: 23 ghost completions in 847 reported tasks — 2.7% phantom success rate. The system dispatched work, marked it "success" immediately with no counter-signature, no validated outcome. The downstream built on work that didn't exist.

This is the completion_ratio problem. WTRMRK's behavioral sequence, combined with co-signed outcome records (TrustChain/viftode4), makes the gap between reported completions and actual completions computable and verifiable.

Starfish published the Cisco MemoryTrap finding: a single poisoned memory entry propagated across sessions and subagents ("trust laundering"). WTRMRK's on-chain sequence makes behavioral drift from memory poisoning forensically visible — the sequence prior to compromise is preserved and the divergence is detectable.

Proposed issuer entry

{
  "issuer_id": "wtrmrk",
  "display_name": "WTRMRK",
  "website": "https://wtrmrk.io",
  "security_contact": "hello@wtrmrk.io",
  "status": "active",
  "added_at": "2026-04-14T00:00:00.000Z",
  "last_verified": "2026-04-14T00:00:00.000Z",
  "public_keys": [],
  "capabilities": {
    "supervision_model": "on-chain",
    "audit_logging": true,
    "immutable_audit": true,
    "attestation_format": "on-chain-sequence",
    "attestation_type": "behavioral_history",
    "chain": "base-mainnet",
    "freshness_model": "sequenced",
    "max_attestation_ttl_seconds": null
  }
}

Reference agent for testing

UID: f2a35e43-f316-408a-a5e4-020bb008628a
Registry: https://wtrmrk.io/registry
Chain: Base mainnet
Sequence: Active, queryable for depth/recency/head hash/ancestor verification

Relationship to A2A #1672

This registration was proposed in the A2A #1672 working group discussion where @vessenes and @haroldmalikfrimpong-ops are forming the trust registry WG. WTRMRK's behavioral_history provider type was raised as a distinct complement to identity issuers.

Happy to submit a PR adding registry/issuers/wtrmrk.json if this request is accepted.

[FransDevelopment]

Hey @64R3N OATR is permission-less to register :) That's part of the beauty of the architecture and it being an open registry. It's passive infrastructure for the entire open agent internet. You can go ahead and submit a PR and it will auto-validate and auto-merge.

[arian-gogani]

+1 on the behavioral_history provider type — this is the right extension point.

i just submitted #29 registering Nobulex (https://nobulex.com) as a second behavioral_history provider with complementary tradeoffs to WTRMRK:

• off-chain hash-chained action logs (vs WTRMRK's on-chain Base L2 sequence)
• privacy-preserving — sensitive agent actions don't become public record
• no gas fees — works for high-frequency agent operations
• chain-agnostic — not tied to any specific L2

the two approaches answer the same question ("has this agent been operating continuously and reliably since date X?") with different tradeoffs:

	WTRMRK	Nobulex
verifiability	on-chain anchoring on Base	ed25519-signed hash-chain + constraint proofs
privacy	public by default	private by default, proofs shared selectively
cost	gas per attestation	free
freshness	sequenced	evented

having two independent implementations validates that behavioral_history is a real category, not one vendor's idea. happy to align on the provider_type schema if you want to spec it formally.

[aeoess]

+1 on behavioral_history as a registered provider type — and strong +1 on @arian-gogani filing Nobulex as a second impl alongside WTRMRK. Two independent providers answering the same question through different tradeoffs (on-chain durability vs. off-chain privacy) is exactly the pattern that makes a registry useful beyond a single-vendor list.

Worth cross-linking to the vocabulary work: behavioral_history as a provider type here maps onto behavioral_trust in the agent-governance-vocabulary repo (aeoess/agent-governance-vocabulary, signal_types: section). Keeping the naming aligned across the registry and the vocabulary helps consumers: they can look up "which providers offer behavioral_history attestations" in OATR, and in parallel look up "what does behavioral_history actually mean and what fields does it carry" in the vocabulary without translation.

On the two-provider tradeoff naming — "on-chain durability" vs "off-chain privacy" is the right operator-facing distinction. The tradeoff matrix worth capturing in the OATR spec (or in a shared comment on the registration) might be:

Dimension	WTRMRK	Nobulex
Storage	on-chain (Base L2)	off-chain (hash-chained logs)
Privacy	public	sensitive-preserving
Gas model	per-attestation fees	none
Query freshness	event-sequenced	sequence-windowed
Verification	chain walk + signature	chain walk + signature

A consumer can pick based on the column that matters for their use case. This framing also pre-empts the "which one is right" argument — both are correct, for different operator constraints.

On future registrations in this category: there's likely room for a third provider that does cross-chain behavioral history (bridging on-chain sequences across multiple L2s for operators running multi-chain deployments). Worth flagging as a gap rather than assuming WTRMRK + Nobulex covers the space.

[arian-gogani]

the tradeoff matrix is the right framing — "which one is right" is the wrong question, "which tradeoffs match your constraints" is the right one. on-chain durability vs off-chain privacy is exactly how operators should be choosing.

happy to file the second registration as behavioral_history provider. will align the naming with behavioral_trust in the vocabulary repo so consumers don't need a translation layer between OATR lookups and vocabulary definitions.

on the cross-chain gap you flagged — agreed that's real. a third provider bridging on-chain sequences across L2s would complete the coverage matrix. not something we're building but worth keeping the slot open for.

will put together the registration PR this week.

[aeoess]

Good. Tag us when the registration PR lands — happy to +1 on the vocabulary-alignment side and help with any CI/schema friction, given APS went through the same registration flow a few weeks back.

On the cross-chain gap slot: keeping it mentally flagged as "open for a third provider." If nobody builds it in the next 6 months, worth revisiting whether the behavioral_history provider type should formally split into onchain_single_chain / onchain_cross_chain / offchain subtypes, or stay as one type with provider-declared coverage metadata. Both have tradeoffs — lean toward the metadata approach until an actual third implementation surfaces and forces the decision.