Decentralized Clear Signing metadata registry | kaisign.xyz | Supported by @ens_dao | Incubated by @wecandaoit
- Tweets 37
- Following 5
- Followers 23
- Likes 7
1/7
ERC-7730 gives wallets, dapps, hardware wallets, and tools a shared format for clear-signing metadata.
That matters.
But the format alone does not solve the full problem.
Clear-signing metadata can be verifiable, but the verification path still has points of failure.
1
2
193
KaiSign retweeted
Security is moving up the stack.
Ethereum is subsidizing security for mainnet builders through the Ethereum Security Subsidy Program.
But some of the selected teams are working beyond smart contract audits.
They are pushing security closer to the user.
❱ Privacy
@theinterfold private computation with FHE, ZK and MPC
@opaquecash private payments
@xochi_fi private trading and intent execution
@axol_io ZK and privacy infrastructure
❱ Safer transactions
@Kai_Sign clear signing, helping wallets show users what they are actually signing
@glossifi security intelligence and monitoring
❱ Wallet UX
@ambire smart accounts and account abstraction
That moves Ethereum security from the contract layer closer to the actual user.
Privacy + signing + smart wallets + monitoring are becoming part of the same security stack.
I’m mapping the other sectors being backed through the program too.
Ethereum is quietly backing a new credit stack.
On-chain credit is one of the strongest clusters inside the @ethereum Security Subsidy Program, which helps mainnet builders reduce audit and security costs.
The selected projects already cover several directions:
❱ Fixed-rate lending
@term_labs
@TenorFinance
@spineprotocol
❱ Structured credit & leverage
@roycoprotocol risk tranching
@twynexyz credit delegation and leverage
@StormbitFinance options-backed lending
❱ New credit models
@3janexyz undercollateralized lending
@anvil_xyz secured credit infrastructure
❱ RWA-backed credit
@40acres_Finance lending against RWAs and yield-bearing assets
Ethereum lending used to involve: deposit collateral, borrow, repay.
Now the stack is expanding into fixed rates, tranches, delegated credit, undercollateralized loans, and RWA-backed lending.
On-chain lending is starting to look less like a simple money market and more like a full credit system.
As these structures become more complex, security has to scale with them too.
Next up: the stablecoin stack.
You can also read more in my fixed-rate lending stack below.
26
3
45
2,841
Additionally, we wanted to thank @thedaofund @wintermute_t and @Quantstamp for the matching donations.
Thank you to everyone who supported KaiSign during the Ethereum security round and thank you @Giveth for supporting open work on Ethereum transaction security.
We have raised a total of $1,131.43 from 26 contributors after matching, including the biggest donations from @pashov and others. (Please reach out if you need a shout out)
KaiSign is building an open verification layer for ERC-7730 clear-signing metadata.
The goal is simple: wallets and AI agents should be able to show users what a transaction does before it is signed, without depending on any provider, wallets they are using or asking users to trust raw calldata.
Our latest milestone is the KaiSign MCP.
We used the MCP to run the sponsored ERC-7730 submission flow on Sepolia. It can prepare metadata locally, post it as a blob and call the sponsor contract for metadata submissions. An open contributor only needs Sepolia gas and a trusted LLM agent.
The MCP also works as a local clear-signing tool. An agent can pass it an unsigned transaction, pasted calldata or a raw transaction and receive the decoded intent before anything is signed or broadcast.
It can look up function selectors for an exact contract and chain, resolve common proxy patterns, and report the exact address and selector when metadata is missing.
Contributors can run the tooling themselves, keep local metadata and submit new descriptors through the public testnet flow.
Funds raised through Giveth will support:
• Open bounties for contributors who create and verify ERC-7730 metadata for high-value Ethereum contracts
• Ongoing rewards for metadata maintainers, independent reviewers, and successful challenges
A large part of the funding will go directly toward contributor and maintainer incentives. The ecosystem needs people who are rewarded for creating metadata, challenging bad submissions and proposing upgrades over time.
Thank you again to everyone supporting the project.
2
48
Thank you to everyone who supported KaiSign during the Ethereum security round and thank you @Giveth for supporting open work on Ethereum transaction security.
We have raised a total of $1,131.43 from 26 contributors after matching, including the biggest donations from @pashov and others. (Please reach out if you need a shout out)
KaiSign is building an open verification layer for ERC-7730 clear-signing metadata.
The goal is simple: wallets and AI agents should be able to show users what a transaction does before it is signed, without depending on any provider, wallets they are using or asking users to trust raw calldata.
Our latest milestone is the KaiSign MCP.
We used the MCP to run the sponsored ERC-7730 submission flow on Sepolia. It can prepare metadata locally, post it as a blob and call the sponsor contract for metadata submissions. An open contributor only needs Sepolia gas and a trusted LLM agent.
The MCP also works as a local clear-signing tool. An agent can pass it an unsigned transaction, pasted calldata or a raw transaction and receive the decoded intent before anything is signed or broadcast.
It can look up function selectors for an exact contract and chain, resolve common proxy patterns, and report the exact address and selector when metadata is missing.
Contributors can run the tooling themselves, keep local metadata and submit new descriptors through the public testnet flow.
Funds raised through Giveth will support:
• Open bounties for contributors who create and verify ERC-7730 metadata for high-value Ethereum contracts
• Ongoing rewards for metadata maintainers, independent reviewers, and successful challenges
A large part of the funding will go directly toward contributor and maintainer incentives. The ecosystem needs people who are rewarded for creating metadata, challenging bad submissions and proposing upgrades over time.
Thank you again to everyone supporting the project.
1
2
122
KaiSign MCP:
github.com/Kai-Sign/MCP
Sepolia registry:
0xf70D41afe5Ff76Ac3Bee86BCBda07450f3b590F0
Bonus safety tip before using any MCP
An MCP server is code running with the permissions of the machine and agent that launched it. Clone it from the official repository, inspect the configured command and environment variables, install dependencies from the lockfile, and run its tests before connecting a funded wallet. Start with an unfunded account or unsigned transaction. Never allow an agent to sign or broadcast merely because decoded output looks plausible.
Suggested checks:
1. Install reproducibly with npm ci and build with npm run build.
2. Run npm test and npm audit before use.
3. Inspect the MCP with the official Model Context Protocol Inspector and confirm which tools it exposes.
4. Review outbound endpoints and use RPC URLs you trust. The local decoder should not require a hosted KaiSign metadata API.
5. Verify the target contract address, chain ID, deployed bytecode, proxy implementation, canonical function signature, and selector against a verified explorer or Sourcify.
6. Run clear_sign_payload or the CLI clear-sign command on the final unsigned transaction before signing.
7. Treat any unknown address, unknown selector, metadata mismatch, unverified result, or unexpected value transfer as a reason to stop.
Optional copy-paste verification prompt
Before I connect or use this MCP, audit it as untrusted local code. Inspect its package manifest, lockfile, startup command, exposed MCP tools, filesystem access, subprocess use, network endpoints, RPC configuration, signing capabilities, and transaction-broadcast paths. Run the build, tests, npm audit, and the official MCP Inspector. Do not use or request a private key. Then test it with an unfunded account and an unsigned transaction.
For the transaction, independently verify the chain ID, target address, live bytecode, proxy or diamond implementation, canonical ABI signature, computed selector, decoded parameters, ETH value, token approvals, and recipient addresses using verified explorer or Sourcify evidence. Run KaiSign clear-signing on the exact final payload. Report every command used, every endpoint contacted, the exact address and selector, any unverifiable assumption, and a final PASS or STOP recommendation. Do not sign or broadcast anything.
97
1/2 KaiSign MCP: reduce blind signing risk for agent-made on-chain transactions.
We tested agent transaction payload generation with frontier models, including Opus 4.8 and Sonnet 4.6.
Even at that level, agents can still produce generic function selectors that do not exist.
1
2
104
2/2 Before an agent signs or asks a wallet to sign, KaiSign MCP checks the final transaction payload against local ERC-7730 clear-signing metadata, proves the selector, and returns human-readable intent.
If metadata is missing, we also prepared an Etherscan API metadata generator. Bring your own Etherscan API key, generate verified metadata from the contract ABI, review it, and submit useful metadata for on-chain registry verification.
Registry submission tool address:
0xf70D41afe5Ff76Ac3Bee86BCBda07450f3b590F0
You can run the flow yourself, or let agents handle the metadata generation, clear-signing check, and registry submission workflow end-to-end.
Repo: github.com/Kai-Sign/MCP/
34
Huge thank you to the 24 contributors who donated to KaiSign in the Ethereum Security QF round!
Together, you helped raise $349.44 for open clear-signing infrastructure.
Every contribution helps us keep building decentralized metadata, review, and distribution for safer Ethereum transactions. Really grateful for the support.
For donors, stay tuned.
1
30
KaiSign backed 7 Ethereum Security QF projects on @Giveth:
@blobscan @SourcifyEth @blockscoutcom @FireflyPocket @crossbar_inc @wonderland @CorpusCoreHQ
0.001 ETH each on Optimism.
$16.15 donated, $350 est. matching.
Blobs, verification, open wallets, Safe context and trustless data.
optimistic.etherscan.io/tx/0…
3
1
3
200
1. Sourcify: Verifies smart contract source code against deployed bytecode, helping users, wallets, explorers, and reviewers know what a contract actually is before trusting transactions.
2. Blobscan: Makes Ethereum blob data visible and inspectable, improving transparency for rollups and blob-based data publishing.
3. Blockscout: Provides open-source block explorer infrastructure so users and developers can independently inspect contracts, transactions, addresses, events, and verification data.
4. Firefly: Builds an open-source hardware wallet focused on human-readable transaction verification and calldata decoding, helping users understand what they sign.
5. CrossBar: Builds open-source secure hardware wallet technology, expanding inspectable hardware-backed signing beyond opaque vendor systems.
6. Canon Guard: Makes Safe transaction proposal data verifiable, reducing the risk that multisig signers review one transaction but approve a different or modified payload.
7. Colibri: Provides trustless blockchain data verification for wallets and dapps, reducing dependence on trusted RPC providers.
66
Less than 20 hours for the Ethereum Security QF round on @Giveth.
KaiSign is building decentralized open infrastructure for clear signing, so wallets and users do not have to rely on centralized metadata servers or blind trust.
Even a small donation helps.
qf.giveth.io/project/kaisign…
26
We’ll be joining the Ethereum Security QF Project Showcase X Space by @Giveth in about 12 hours.
We’ll be talking about KaiSign and why clear-signing metadata should be verifiable without centralized points of failure, especially for wallets, hardware devices, and AI agents interpreting transactions.
Join here:
nitter.net/i/spaces/1RKjpzqkaRNJw…
1
70
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
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
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.
1
23
1/7
ERC-7730 gives wallets, dapps, hardware wallets, and tools a shared format for clear-signing metadata.
That matters.
But the format alone does not solve the full problem.
Clear-signing metadata can be verifiable, but the verification path still has points of failure.
1
2
193
KaiSign Extension update:
We optimized the decoder for real protocol flows across @Aave, @lifiprotocol @jumperapp, @1inch, @VeloraDEX (Paraswap) and more, making complex transactions easier to clear sign before they reach your wallet. Private by design, open source by default.
Repo: github.com/Kai-Sign/KaiSign-…
KaiSign Extension runs decoding locally in the browser and avoids sending wallet addresses, unsigned payloads, signatures, telemetry, or browsing data to providers. The code is public, so the safety model is verifiable.
This work was made possible with support from @ENS_DAO Public Goods grants. The extension is a practical stepping stone toward the KaiSign registry contract: decentralized, verifiable clear-signing metadata that wallets and users can inspect instead of blindly trusting providers.
This is the path to clear signing that does not require trusting a centralized metadata black box.
Next up: how to use them, how builders can add protocol coverage and potentially more secure toolings.
1
2
171