Hi ENS community,
I would like to open a technical discussion around project Siren and how it should align with ENS-native identity and discovery patterns.
Siren is a public verification and scoring layer for ENS-named agents, projects, companies, teams, and on-chain entities.
The basic idea is simple:
More agents and projects will use ENS names as their public identity. But an ENS name alone does not tell an investor, launch platform, partner, or user whether that entity is active, credible, or backed by real public evidence.
Project Siren tries to fill that gap.
A user enters an ENS name, and Siren reads public evidence around that subject, such as ENS records, GitHub activity, on-chain activity, and verified contract data. It then produces a transparent benchmark score, tier, risk signal, and report.
The result can also be represented as an EAS attestation / benchmark certificate with a payload similar to:
{
"subject": "0x...",
"ensNamehash": "0x...",
"score": 82,
"tier": "A",
"computedAt": 1770000000,
"reportHash": "0x...",
"reportUri": "https://..."
}
In the current implementation, project Siren already has an ENS-specific subject manifest namespace:
agent-bench:bench_manifest
agent-bench:owner
agent-bench:schema
This manifest can declare the public sources that should be evaluated for a subject.
For subjects without an explicit manifest, Siren also has a public-read fallback. It reads common ENS records such as:
com.github
description
url
avatar
com.twitter
com.linkedin
and also looks for contract/source hints such as:
org.sourcify
sourcify
Sourcify
contract
verified-contract
agent-bench:contract
agent-bench:contracts
This already works technically, but it raises a bigger design question:
What should be the ENS-native way to link an ENS name to a verifiable benchmark certificate?
My current mental model is:
ENS name = public identity
ENS records = discovery surface
Project Siren = evidence + scoring layer
EAS attestation = portable benchmark certificate
reportHash/reportUri = reproducible evidence object
What I would like to understand from the ENS developer community:
-
Should an ENS name store only a pointer to the latest Siren/EAS attestation, or should selected metadata such as
score,tier, andreportUrialso be exposed as text records? -
Would it make sense to use an ENSIP-26-compatible pattern for agents, for example
agent-contextandagent-endpoint[web], rather than creating a separate Siren-only discovery model? -
If project-specific records are useful, would a namespace like this be acceptable?
siren:attestation_uid
siren:attestation_network
siren:report_uri
siren:report_hash
siren:score
siren:tier
siren:updated_at
- Or would it be better to keep ENS records minimal and store only something like:
siren:latest = eip155:11155111/eas:0x...
with all score details living inside the EAS attestation and report?
-
Should the canonical attestation live on the same chain as the subject, on mainnet, on Base/Optimism, or should the network be explicitly encoded in the ENS record?
-
How should updates be handled? If a Siren score changes over time, should ENS point to the latest attestation, an attestation history, or only to a stable report endpoint?
-
Is it dangerous or misleading to expose
scoreandtierdirectly in ENS records, since they may become stale while the underlying evidence changes? -
Would ENS clients prefer flat records, a single JSON manifest, or a hybrid where ENS stores a small pointer and the full schema/report lives offchain or in EAS?
-
Is there already a preferred ENS pattern for linking names to attestations, reputation objects, verification reports, or credentials?
-
From a UX perspective, could a future flow make sense where a user enters a Siren attestation UID, and a UI pre-fills suggested ENS records for the ENS name owner to review and sign?
To be clear, I am not suggesting that project Siren should automatically write to someone else’s ENS records. The ENS name owner should remain fully in control.
The question is about the cleanest representation:
How should an ENS identity discover, reference, and expose a verifiable benchmark certificate without duplicating too much mutable data inside ENS records?
I would appreciate feedback on whether this direction makes sense, which records should be used, and what the cleanest ENS-native integration path would be.