What Ligate is for

Six months ago an AI startup founder asked me on a Zoom call: "how do you prove a human actually asked for that AI output?"

I had nothing. Just sat there.

That conversation is why Ligate exists. Not to ship four products. To ship a chain where any app can make a verifiable claim about a real-world event without each app rebuilding the same attestation plumbing.

Most of the public copy on this site introduces the four flagships: Themisra, Mneme, Iris, and Kleidon. Investors and design partners keep asking the same follow-up. What is the chain actually for, beyond the four products you happen to be building? This post is the answer.

Attestation as the protocol primitive

Most chains can do attestations. They can do them the way most chains do anything: by deploying a contract. The cost shows up later, when ten thousand apps each invent their own slightly different attestation contract and nothing composes.

Ligate makes attestation the primitive, the same way Ethereum made transaction the primitive. Schemas, attestor sets, and reputation-weighted validators are protocol-native, not application-layer plumbing.

That sounds technical. It buys you five things that are genuinely different from "implement an attestation contract on a generic chain."

1. Permissionless schema registration

Anyone declares a new attestation type without forking the chain and without asking anyone for permission.

A schema is a declaration. "This is what an attestation of type X looks like, these are the fields, these are the attestors who can sign it, this is the fee market." Once registered, anyone can submit under it. No governance vote. No core team gatekeeper.

Compare this to EAS on Ethereum, where the same idea works fine but each schema is a contract deployment with its own gas overhead and quirks. Or to KYC services that gate-keep attestation types behind partnerships. Ligate makes schema registration a first-class chain operation, like minting an NFT used to be.

2. Reputation-weighted validator security

Validators on Ligate are weighted by stake AND a non-transferable reputation earned by signing attestations correctly over time. The full machinery is in the PoUA paper. The marketing version: validators have skin in the game on attestation quality, not just block production.

A validator who signs sloppy attestations loses reputation. A validator who signs reliably gains it. Stake-weighted Byzantine fault tolerance is a solved field. The reputation modulation is the part that makes attestation-as-workload economically viable. If you are attesting medical license validity, you want the validators who sign that schema to be the ones who have gotten medical attestations right for a year, not just the ones who happened to put up the most stake last week.

3. Cross-app composability for free

An attestation made for App A is readable by App B by default. Same chain, same schema registry, no oracle, no API key, no rate limit.

Think about an AI agent ecosystem. Agent A attests "I called this LLM with these inputs, here is the receipt." Agent B reads the attestation when deciding whether to trust agent A's claim about a downstream task. No API contract between the two agents. No shared infrastructure to operate.

Or think about identity. An "I am a verified Stripe merchant" attestation in one app is consumable by any other app that respects that schema. No SDK to install, no partnership to negotiate.

This is the Lego-bricks property. It is hard to overstate how much easier it makes building the next generation of multi-app workflows.

4. Per-schema fee markets

High-value schemas (court-grade evidence, medical license verification) command higher fees than low-value schemas (anonymous review, casual bookmark). The fee market is per-schema, not chain-wide.

The reason is simple. The most valuable attestations need the most economic security. The most casual attestations need to be cheap, fast, and good enough. A single chain-wide fee market either prices out the casual workloads or under-secures the high-stakes ones. Per-schema fee markets solve both at once.

We wrote about this in more detail in the per-schema fee markets post a couple of weeks back.

5. Explicit attestor sets

When a schema requires specific attestors to sign, that requirement lives in the schema itself, not in some off-chain governance.

A "medical license verified" schema can require committee signatures from a registered medical board. A "GitHub commit signed by employee X of company Y" schema can require GitHub-the-OAuth-attestor and Company-the-employer-attestor.

This is harder than it sounds. Most attestation systems pick one of two failure modes: too permissive (anyone signs anything, garbage in garbage out) or too centralized (the chain operator gates which attestors are allowed). Schemas with explicit attestor sets are the middle path, and it is the path that lets the protocol stay neutral while individual schemas pick the trust model that fits their workload.

What you can actually build

I keep getting the same question from investors and design partners. OK but Themisra, Mneme, Iris, Kleidon. What else?

Categories below. Specific examples within each, not just labels.

Provenance and authenticity

• Photo authenticity at capture. A camera signs the moment a photo was taken: timestamp, GPS, model, sensor hash. The receipt lands on chain. When the image surfaces in court six months later, the attestation is the chain of custody.
• Document notarization. Hash a document, sign with a registered notary, publish. Lighter and faster than traditional notarization, with a cryptographic identity instead of a wax seal.
• Code commit provenance. GitHub signs "yes, this commit came from this user, on this date, in this repo." Useful for compliance audits, supply-chain security, and bounty payouts where you want to verify the work actually came from the claimed contributor.
• Journalism source attribution. A photographer signs a photo and the receipt becomes part of the byline. Newsroom can verify the attribution is real, not just claimed in metadata.

Credentials and identity

• Educational degrees. University signs "this person earned this degree on this date." Employers verify with a chain query instead of a registrar phone call.
• Professional licenses. Medical board signs "Dr. X holds an active license in state Y as of date Z." No more waiting for fax-confirmed transcripts.
• KYC results without revealing PII. "Person X passed KYC on date Y for use case Z" without the actual ID details on chain. The KYC provider holds the personal data; the chain holds the receipt that the check happened.

Real-world data feeds

• IoT cold-chain compliance. Refrigeration sensors sign "temperature stayed within 2-8°C from time A to time B." Pharmacy shipments arrive with verifiable temperature attestations attached.
• Environmental monitoring. Sensor networks attest air quality, water quality, soil chemistry. Each measurement is a chain receipt that researchers, regulators, and locals can verify independently.
• Carbon credit issuance with auditable verifiers. Carbon credits are currently a swamp of trust-based verification. Chain-native attestations give every credit a receipt chain back to the auditor, the methodology, and the date of measurement.

Marketplace reputation

• Verified-buyer reviews. "This reviewer actually purchased this item." Today this requires either a captive marketplace (Amazon's verified-purchase system) or a centralized reputation service. Chain attestation lets any marketplace participate in a shared reputation pool.
• Service provider ratings. "Worker X completed task Y for client Z, with rating R." The receipt is the work history. Useful for freelance platforms, real estate agents, contractors.
• Counterfeit detection for luxury goods. Manufacturer signs at production. Resellers re-sign at transfer. The chain has the full provenance from factory to display case.

Compliance and audit

• Regulatory inspection records. "Inspector X visited facility Y on date Z and found compliance with rules R." Today this is filed in PDFs that are easy to lose or alter. Chain attestation is the immutable filing system.
• Tax filing receipts. Filing acknowledgment as a chain attestation. Useful in jurisdictions where filings are paper-based or where audit trails are needed years later.
• Audit reports. Big-four auditors sign their findings. The chain becomes the registry of who audited what and when. Smaller auditors can compete by registering their own schemas.

Gaming

• Speedrun verification. A community-attested speedrun is a chain of attestations: the player, the run video hash, the verification by judges. No more "screenshots of leaderboards that the operator can edit."
• Tournament results. Esports tournaments where the chain holds the official results, signed by the tournament organizer plus key judges.
• In-game achievement provenance. Achievements that move with the player, not the platform. Kleidon SkinsVault is in this space.

AI agent ecosystems

• Agent action attestations. When an autonomous AI agent takes an action, that action gets a receipt. Useful for liability, payment, and audit.
• MCP server output attestations. When an MCP server returns a result to a calling agent, the result is signed. Iris is in this space.
• Multi-agent delegation chains. Agent A delegates to Agent B, who calls Agent C. Each delegation step is an attestation. The full chain is the audit log.

Healthcare, finance, real estate

• Clinical trial data attestation. Each measurement in a clinical trial is a receipt. Researchers correlate findings to specific attested measurements, not aggregated CSVs.
• Penetration testing reports. Signed by the auditor, dated, immutable. Useful for SOC2 audits, insurance claims, and post-incident forensics.
• Property inspection records. "Property at address X had inspection on date Y by qualified inspector Z." Useful for insurance, real estate transactions, dispute resolution.
• Title chain history. Real estate title transfers as chain attestations. Cleaner than the current paper-trail system in most jurisdictions.

When you should NOT use Ligate

Honest section. Four reasons not to.

Your attestations fit cleanly in EAS on Ethereum. EAS has years of network effects, a working tool ecosystem, and lots of mindshare. Ligate is pre-launch (devnet ships Monday May 11). If your use case is well served by an existing Ethereum-native attestation system, use that. Don't migrate for the sake of migrating.

You need the attestation itself hidden, not just the underlying data. Ligate is public-by-default at the protocol layer. Schemas can carry external zk-proof hashes (zkML, TEE, zk-friendly commitments) in their payloads, and v2+ schema specs are designed to support exactly that. So if you want to attest a fact without revealing the data behind it, that path is on the roadmap. But if you need the attestation existing at all to be hidden, zkPassport, PolygonID, and similar zero-knowledge-first identity systems are purpose-built for that. We stay neutral on proving tech and do not build our own zkML.

Your "attestation" is just a timestamp. Bitcoin OP_RETURN works fine. Don't pull in a full attestation framework when a single hash plus timestamp is all you need.

Your app needs general compute or EVM contracts. Use an EVM chain. Ligate is not a general execution platform. The validators and the fee markets are optimized for attesting, not for arbitrary smart contracts.

The thesis in one paragraph

A generation of apps wants to make verifiable, composable claims about real-world events and have those claims survive audit, court, regulation, and time. Today, each app rebuilds the same attestation infrastructure on top of generic chains or in centralized databases that fail under scrutiny. Ligate is the chain where that infrastructure is the protocol, not application code. The four flagships seed the ecosystem. The actual win is third parties registering their own schemas because the primitive is permissionless. If that bet is wrong, Ligate looks like an over-engineered EAS competitor. If it is right, Themisra, Mneme, Iris, and Kleidon are the first four of hundreds.

Public devnet ships Monday May 11.

Code is at github.com/ligate-io/ligate-chain. Docs at docs.ligate.io. Discord at discord.gg/ZWUeJ8k3eP. The PoUA paper that powers the validator economics is in the research repo.

If you build anything that needs a verifiable receipt for a real-world event, this is for you.