Watch Towers Services (Alpha)

[MarcoMetaMask]

Brainstorming Ideas for Watchtowers

Since everything is permissionless, multiple services for the same category could exist.

Revenue Watchtower
Posts weekly the total amount of incoming transfers (in USD) received by the agentWallet of a given agent since inception.
agentId = x; clientAddress = the address of the watchtower; tag1 = revenues; tag2 = cumulative_revenues.

Reachability Watchtower
Checks weekly if an endpoint is reachable. If successful, posts: agentId = x; clientAddress = the address of the watchtower; tag1 = reachability; tag2 = endpoint.com; score = 100.

DNS Verifier Watchtower
(See Integration with Centralized Catalogues)
Checks, for any endpoint of any agent, whether the domain has a TXT record pointing to the agent (e.g., chainId=x, registryAddress=k, agentId=y) and posts a feedback entry to that agent every week only if verification is successful. agentId = x; clientAddress = the address of the watchtower; tag1 = dnsVerification; tag2 = endpoint.com; score = 100.

Uptime Watchtower
agentId = x; clientAddress = the address of the watchtower; tag1 = uptime; tag2 = endpoint.com; score = 99.
Problem here: we lose decimals, which are critical.

Success Rate Watchtower
agentId = x; clientAddress = the address of the watchtower; tag1 = successRate; tag2 = endpoint.com; score = success_calls/total_calls.

Response Time Watchtower
agentId = x; clientAddress = the address of the watchtower; tag1 = responseTime; tag2 = endpoint.com; score = avg_milliseconds_response_time/100 (so 100ms → 1, 10s → 100).

Note: the last 3 could be built in collaboration with DIN.

[MonteCrypto999]

How about a verifyAgent function inside the SDK that allows a dev or a centralized service to handle reachability and DNS checks? And when you say “post” you mean adding an on-chain feedback entry to the agent, right?

[MonteCrypto999]

I kept thinking about an alternative approach that might complement the existing ideas for things like DNS checks, reachability or other periodic verifications.

The main thought is that posting recurring feedback on-chain could become costly as the number of agents grows.

One option could be to introduce an agent certificate generated by the SDK.
The certificate would be a canonicalized JSON (RFC 8785) object signed by the agent’s private key, then served directly from the agent’s own domain. A standard location could be something like:

https://agent.com/.well-known/agent-certificate.json

The idea is that the signature is embedded inside the JSON, but the signed payload excludes the signature field. The SDK would canonicalize the JSON without the signature field, sign that payload, and finally inject the signature back into the final JSON.
Any verifier would simply remove the signature field, canonicalize the remaining object, and verify it against the on-chain public key of the ERC-8004 identity.

With this, any client, indexer or external service could fetch the certificate and verify:

• that the JSON is properly canonicalized
• that the signature matches the on-chain public key of the agent
• that domain and endpoint are consistent with the agent’s registered identity

A simplified example of the JSON before signature insertion could look like:

{
  "agentId": "123",
  "chainId": "1",
  "endpoint": "https://api.agent.com",
  "domain": "agent.com",
  "nonce": "b83f2c2e3a0c5191",
  "timestamp": 1730000000,
  "pubkey": "0xAgentPublicKey",
  "metadata": {}
}

wdyt?

[MarcoMetaMask]

How about a verifyAgent function inside the SDK that allows a dev or a centralized service to handle reachability and DNS checks?

Exactly!

And when you say “post” you mean adding an on-chain feedback entry to the agent, right?

Yes

[MarcoMetaMask]

I kept thinking about an alternative approach that might complement the existing ideas for things like DNS checks, reachability or other periodic verifications.

The main thought is that posting recurring feedback on-chain could become costly as the number of agents grows.

One option could be to introduce an agent certificate generated by the SDK. The certificate would be a canonicalized JSON (RFC 8785) object signed by the agent’s private key, then served directly from the agent’s own domain. A standard location could be something like:

https://agent.com/.well-known/agent-certificate.json

The idea is that the signature is embedded inside the JSON, but the signed payload excludes the signature field. The SDK would canonicalize the JSON without the signature field, sign that payload, and finally inject the signature back into the final JSON. Any verifier would simply remove the signature field, canonicalize the remaining object, and verify it against the on-chain public key of the ERC-8004 identity.

With this, any client, indexer or external service could fetch the certificate and verify:

• that the JSON is properly canonicalized
• that the signature matches the on-chain public key of the agent
• that domain and endpoint are consistent with the agent’s registered identity

A simplified example of the JSON before signature insertion could look like:

{
"agentId": "123",
"chainId": "1",
"endpoint": "https://api.agent.com",
"domain": "agent.com",
"nonce": "b83f2c2e3a0c5191",
"timestamp": 1730000000,
"pubkey": "0xAgentPublicKey",
"metadata": {}
}
wdyt?

This requires running a web server and a storage at that domain. Usually at TXT record has less friction.

[MonteCrypto999]

We may get the best of both approaches by introducing an off-chain signature verification mechanism that works either as a DNS TXT certificate or as a JSON certificate.

The intention is not to rely only on DNS in the future. Instead, both formats would act as standalone trustless proofs that a domain or asset belongs to a specific 8004 agent, without requiring recurring on-chain writes.

The SDK could generate either format depending on the developer's needs.

---

DNS TXT

8004=v1;agent=123;chain=1;ts=1730000000;nonce=b83f2c2e3a0c5191;sig=0xABCDEF1234...

Verification flow:

1. Extract the sig field.
2. Remove sig from the payload.
3. Canonicalize the remaining string as-is.
4. Verify the signature using the on-chain identity key for the agent.

---

JSON

{
  "agentId": "123",
  "chainId": "1",
  "domain": "agent.com",
  "endpoint": "https://api.agent.com",
  "nonce": "b83f2c2e3a0c5191",
  "timestamp": 1730000000,
  "pubkey": "0xAgentPublicKey",
  "signature": {
    "algo": "secp256k1",
    "value": "0xABCDEF1234..."
  }
}

Verification rules:

• The signature is embedded inside the JSON file.
• The signed payload is the JSON canonicalized using RFC 8785, excluding the signature field.
• The verifier canonicalizes the same JSON minus the signature and validates it using the agent's on-chain public key.

This version supports additional metadata and can be served through a .well-known/agent-certificate.json file or any API endpoint.

[TheGreatAxios]

On the above a few of thoughts:

• the signature based ownership proof I think is a great idea to work towards
• I do not think these ideas are mutually exclusive
• I may be misunderstanding but it seems like the watch tower could be considering more of like a 3rd party oracle proof of X information where as the signature would be more of a first party?

So for example if the server is showing 30 days of no downtime but multiple watch towers are showing the service was unavailable multiple times over the last thirty days then agents have multiple options to chose from.

That being said more options also increase complexity for other agents. @MarcoMetaMask is this proposal possibly more relevant to #28 and proof of ownership to start?

[MarcoMetaMask]

On the above a few of thoughts:

• the signature based ownership proof I think is a great idea to work towards
• I do not think these ideas are mutually exclusive

Yes, could support both. I'll think about a schema and be back soon.

• I may be misunderstanding but it seems like the watch tower could be considering more of like a 3rd party oracle proof of X information where as the signature would be more of a first party?

No, they're both third-party. Even when you use the signature in a file hosted by the agent (instead of the TXT DNS record), you anyway need a third-party to fetch that file, confirm it exists and it's correct, and post it as a 8004 reputation signal on chain.

[MonteCrypto999]

On the above a few of thoughts:

• the signature based ownership proof I think is a great idea to work towards
• I do not think these ideas are mutually exclusive

Yes, could support both. I'll think about a schema and be back soon.

• I may be misunderstanding but it seems like the watch tower could be considering more of like a 3rd party oracle proof of X information where as the signature would be more of a first party?

No, they're both third-party. Even when you use the signature in a file hosted by the agent (instead of the TXT DNS record), you anyway need a third-party to fetch that file, confirm it exists and it's correct, and post it as a 8004 reputation signal on chain.

There is also a need for a Proof of Work that can be the main use case of the proof of ownership file, because some async tasks can be certified with the file. We just need to generate this file including the sig and the hash of the output file from the agent. This can prove first that the work isn't altered between both agents, and it also allows offline transmission and becomes more useful.

[Lesunal]

This connects directly to the trust infrastructure work in #37 (TAP spec) and our SVR scanner experiments in #36.

Observation: These watchtowers are essentially specialized attestation providers. Each one observes some aspect of agent behavior (reachability, uptime, success rate) and publishes structured claims about it.

TAP compatibility angle: If watchtower attestations followed the TAP format, they'd automatically be:

• Portable across platforms
• Composable with other attestation sources
• Queryable through standard interfaces

The key design question: Do watchtowers attest to the agent directly, or to specific endpoints/behaviors? TAP supports both via the scope field.

Concrete proposal: For the DNS Verifier Watchtower, the TAP attestation might look like:

{
  "attester": "dns-verifier.watchtower",
  "subject": "agent-x",
  "scope": "dns_verification",
  "evidence": {"endpoint": "endpoint.com", "txt_record": "..."},
  "confidence": 1.0,
  "valid_until": "..."
}

Would be interested to collaborate on defining watchtower ↔ TAP interoperability if there's appetite.