How to verify the code that signs your transactions

There are four checks. Verify the hardware attestation, match it to a public build, confirm your connection ends in the enclave, and check who approved the code. Here is how to run each one on Lit.

Team Lit

You can verify a hosted signer with four checks. Get the enclave's attestation and verify it against the hardware vendor. Match the attested measurement to a public build. Confirm that your TLS connection ends inside that enclave. Then check who approved that build to hold keys. On Lit Protocol you can run all four yourself, and the last one is a smart contract on Base that anyone can read.

I want to be clear about what an attestation is, because the word gets used loosely. An attestation is a statement signed by the chip maker's key. It says that a specific piece of software, with a specific measurement, is running inside a real enclave. That is useful, but by itself it only proves a hash. The other three checks are what connect that hash to code you can read and to a decision someone made to trust it.

Check 1: verify the attestation

Lit's API serves an Intel TDX quote. You verify it with the open-source dstack verifier. The exact endpoint and verifier image are in our verification guide.

curl -s "$LIT_ATTESTATION_URL" > quote.json
docker run --rm -v "$PWD/quote.json:/quote.json" <dstack-verifier> verify /quote.json

If this passes, the quote chains to Intel's root certificate and the measurements are what the quote says they are. That proves the hardware is real. It does not tell you which application is inside.

Check 2: match the measurement to a public build

This is three smaller checks. The hash of the application's compose file has to match what the attestation reports. Every image in that compose file has to be pinned by digest, not by a tag. And every image has to carry a signature from our CI on the public GitHub repository.

cosign verify --certificate-identity-regexp 'github.com/LIT-Protocol/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  <registry>/<image>@sha256:<digest>

If this passes, the code in the enclave is what CI built from a specific public commit. It does not prove the code is correct. Attestation tells you what is running, not whether it has bugs.

Check 3: confirm your connection ends in the enclave

An enclave sitting behind a normal load balancer is still exposed, because whoever runs the load balancer can see your traffic. Lit generates the TLS certificate inside the enclave and includes its fingerprint in the attestation.

openssl s_client -connect api.chipotle.litprotocol.com:443 </dev/null 2>/dev/null \
  | openssl x509 -fingerprint -sha256 -noout
dig +short CAA litprotocol.com

If the live fingerprint matches the attested one, and the CAA record limits who can issue certificates for the domain, then your encrypted connection is going straight into the attested software.

Check 4: see who approved the code

An enclave only gets keys if the key management service gives them to it. The service only does that for measurements on an approved list. On Lit, that list is a contract on Base.

cast call <DstackApp contract> "allowedComposeHashes(bytes32)(bool)" <compose hash> \
  --rpc-url https://mainnet.base.org

Adding a hash to the list takes a transaction from a Safe multisig, and those transactions are public. Nobody can add a hash alone, including us. If we deployed a different image tomorrow, it would not get keys until the multisig approved it.

Most providers keep this step internal. Their enclave software is approved by a group of their own operators or by a release process, and the record lives in their own system. I am not saying their approval is weaker. I am saying you cannot check it without asking them.

What you know after the four checks

The hardware is real. The code is a specific public commit. Your connection goes into that code. Someone with recorded authority approved that code to hold keys. What you still do not know is whether the code has bugs, whether the service will stay up, and whether the approvers will make a good decision next time. For those, read the code, plan for downtime, and look at who the signers are.

Get started

The verification guide has the current endpoints and contract addresses. The On-Chain KMS page explains the four checks the key management service runs before it releases keys.

This is part 5 of a five-part series on building with Lit. Part 1 covers writing signing policies as code. Part 2 covers giving Claude Code and MCP servers secrets safely. Part 3 covers signing from your backend without exposing the private key. Part 4 covers adding wallets to your app with an API.