Every conversation about Ligate runs into the same question, eventually: why is this not an Ethereum smart contract? Every conversation, including the ones I have in my own head when nobody is around to ask. It is a fair question. It is also the wrong one, but explaining why takes a minute.
This post is the why. No mechanism specifics, no formulas, no benchmark numbers. The technical paper for that lives in the research repo and gets better when people open issues. Here, just the argument.
Three things go wrong when you put attestation work on a chain built for something else. Then a precedent that should be familiar by now. Then where this is going.
The composability tax you are paying for nothing
A receipt that says "this AI call happened, here is the model, here is the prompt hash, here are the signers" is small. About 200 bytes. One hash, a quorum of signatures, a write to data availability. The execution layer should not need to think about it again.
On Ethereum it pays the same auction premium as a 200-call DeFi transaction. Block space is shared with every flash loan and every NFT mint, gas is priced for the worst-case caller, and a contract that holds a 200-byte receipt pays the same storage cost as a contract holding nine figures of TVL. Storage on a smart-contract chain is permanent. Replicated to every full node. Audited every time anyone reads it.
You did not need any of that. You wanted a receipt. You are paying for the right to have it mingle with the largest financial state machine ever shipped, and there is no discount for being smaller.
We have done this before, by the way. The first ERC-721 mint cost more than a year of equivalent storage on a chain actually built for media references. The market figured that one out without a whitepaper.
Bring-your-own-contract is a tooling problem, not a protocol
Second thing. On a general-purpose chain, the only way to publish a new attestation type is to deploy a contract, write an ABI, hope the indexers catch it, and watch as people ship three almost-identical variants of the same idea.
EAS solved this on Ethereum, partially. It is excellent inside its niche and we use it as reference. But the schema layer is application code, not a protocol primitive. The chain does not know two attestation contracts are the same shape, and the indexers cannot, and the SDKs all paper over this with a fork-the-types-and-pray pattern that works until it does not.
A chain with schemas in the state machine, with signatures over the
schema id itself, can reason about them. You register a schema once,
anywhere on the network, and every reader resolves it the same way.
themisra.proof-of-prompt/v1 is one schema. The next person who
registers theirs gets the same indexing surface and the same
verification rules without asking us. That is a protocol property, not a
gentleman's agreement between SDK authors.
The validators are securing the wrong thing
This is the deepest one and it is the one that bothers me most.
A chain's consensus is its security model. On a general-purpose L1, validators get paid in proportion to the capital they will lock against the chain's overall continuity. Their job is ordering transactions and not double-spending. Whether your attestation is real, whether the signers are who they claim, whether the schema is being used as written: none of that is in the validator's job description on a chain built for value transfer. It cannot be. The protocol does not have a vocabulary for it.
You can bolt on attestor networks at the application layer. You can slash in user space. The chain still does not care. Stake-weighted consensus is doing the job it was built for.
A chain that exists to settle attestations should care. The validators should be selected, weighted, and paid for doing the work the network exists to do. Otherwise the security budget secures the wrong thing, which sounds abstract until you remember it is the difference between $30B/yr of issuance pointed at bridge contracts and the same money pointed at the integrity of receipts.
We have run this argument three times
This is not a new claim. The history of the last decade makes it embarrassingly often.
Bitcoin script could host smart contracts. Ethereum showed up and a generation of developers found out that "could host" and "is the right substrate for" are different sentences.
Storage could be an Ethereum contract. IPFS pinning was, for a while. Filecoin showed up with validators paid to keep specific bytes available and the economics actually closed. Storage is not on Ethereum.
Wireless coverage could have been ERC tokens. Helium said no, gave coverage proofs their own primitive on a chain that knows what coverage is, and then changed its mind about which chain. The argument survived the migration. The principle did not.
Each time the same observation, dressed up differently. When the work the network secures has a specific shape, the consensus that secures it should know that shape. Generality is a bug at scale. Receipts are the next round of that.
Where the research is going
The research arm is public for a reason. We are not claiming to have shipped any of this. We are saying the question deserves a reviewed answer, and that we would rather be argued with than agreed with too politely.
There is a draft on consensus that ties validator influence to the actual work the chain processes, instead of stake alone. There are notes on per-schema fee markets so a popular schema does not crowd out a niche one. A sketch of native delegation, which is the foundation for the way Iris signs on behalf of agents that do not hold wallets. A thread on cross-schema composition that lets receipts reference each other without trusted bridges. A note on time-locked attestations for when you want to commit now and reveal later (eval shops, sealed bids, a few other cases that show up more often than you think).
These are working drafts. They will change. Some of them are probably wrong. Iteration in public is the point and so is being told you are wrong by someone who read the proof.
If you want to read where this has got to, the papers and roadmap live at github.com/ligate-io/ligate-research. If a particular argument lands wrong on you, the tracker accepts patches. We argue back, when we have time.
The vision is simple, even if the work is not. Attestation is a specialisation of the chain's job, not an application running on top of it. The cycle that put storage and bandwidth and compute on their own substrates will put receipts there too. We are early enough that the research repo is the place this argument gets built. The smart-contract version of it is going to lose for the same reason every previous one did.