2/7
Today, clear-signing metadata verification can still depend on centralized actors:
wallet vendors
hardware wallet vendors
curated metadata sources
closed review processes
controlled distribution paths
That means users may still depend on one party to decide what metadata is accepted, rejected, updated, or removed.
May 13, 2026 · 2:18 AM UTC
1
23
3/7
KaiSign is built to reduce those points of failure.
It is an on-chain registry for ERC-7730 metadata.
Metadata is tied to contract bytecode, attested on-chain, bonded, challengeable, and finalized.
The goal is not “verification from nothing.”
The goal is removing centralized chokepoints from metadata verification.
1
21
4/7
For now, KaiSign is selecting early attesters before opening attestation more broadly.
This is intentional.
Bad metadata can be as dangerous as blind signing.
A fake clear-signing explanation can make a malicious transaction look safe.
Attesters help review, submit, challenge, and improve metadata quality.
1
18
5/7
The registry flow is accountability-based:
prepare ERC-7730 metadata
→ commit the submission
→ approve the bond token
→ reveal the metadata hash
→ Oracle resolution
→ finalize approved metadata on-chain
Only finalized metadata becomes discoverable as an attested KaiSign entry.
1
37
7/7
Repo:
github.com/Kai-Sign/MCP/blob…
Use the repo to run the minimum CLI:
test ERC-7730 metadata locally, clear-sign calldata, and inspect readable transaction intent before submitting.
Docs:
kaisign.gitbook.io/kaisign/d…
Use the docs to submit metadata on Sepolia:
commit → approve bond token → reveal → oracle submission → finalize.
59

