Machine-checked evidence about deployed code
Veric states, in a form a third party can re-check, who controls a deployed smart contract and what it can do. We start with stablecoins and tokenised assets.
The question
Before a token is listed, lent against or held, someone has to answer a plain question: who can upgrade it, mint it, pause it or freeze it, and how much warning would anyone get?
Today that is answered by a person reading contracts and on-chain settings by hand, once, and writing it into a report. The answer is correct on the day it is written. It says nothing about the day after an upgrade, a new chain or a change of keys.
What we produce
A controls statement is a signed, machine-checkable statement about one deployed contract.
| Field | What it holds |
|---|---|
| Subject | The chain, the address, the hash of the deployed code, and the block the statement is about |
| Statement | One precise claim, for example "only this role can upgrade the contract, and only after this delay" |
| Verdict | Proved, refuted with a concrete witness, or stated and not yet proved |
| Assumptions | Every assumption the verdict rests on, listed |
| Not claimed | What the statement deliberately does not cover |
| Signature | Who issued it. Changing any field breaks verification |
Statements are designed to be re-issued when anything changes. A watcher re-reads the certified state with verified storage proofs and withdraws exactly the statements whose facts have changed.
How the answer is established
| Kind of row | What backs it |
|---|---|
| Proved or refuted | A proof checked by the Lean kernel, over a model of the contract |
| Configuration read | A script-level read of on-chain settings at a pinned block, re-runnable at any later block |
| Open | Stated, with the reason it is not yet settled |
What exists today(as of 15 November 2026)
- One live stablecoin, end to end. Several hundred signed statements at a single block, each marked proved, refuted with a witness, or not yet proved. A little under half are proved so far.
- Re-checkable by someone else. A person we give access to can re-derive every verdict with one command, in about eleven minutes on a laptop.
- Bridge routes. Signed, re-runnable checks of a token's cross-chain configuration: for each route, the required verifiers, and who can change them. These are script-level checks, not proofs.
- The foundation underneath. Lean 4 mirrors of Ethereum's Python execution specifications for four forks: Cancun, Prague, Osaka and Amsterdam. Each is pinned file by file, by hash, to an execution-specs commit. On the official
tests@v21.0.2release, the Prague, Osaka and Amsterdam mirrors pass every state and blockchain test for their fork: 45,492 state entries and 60,328 blockchain tests, with no failures, last run 5–6 November 2026.
Not yet: a signature from an independent auditor; a continuously running watch offered as a service; proofs of behaviour for tokens built with older compiler settings; public tooling.
Who it is for
| Token issuers | Show risk reviewers and examiners who controls your token, and show it again after every change, without commissioning a new report each time |
|---|---|
| Auditors | Re-run a check instead of re-reading. The statement lists what it does not claim, which is where your judgement stays |
| Risk reviewers | Cite a statement you can re-check yourself, tied to a block and a code hash, and see exactly what changed since last time |
Why now
Code has become cheap to write and no cheaper to trust. Review, audit and compliance evidence still assume a person reads everything that matters. We think the durable answer is evidence a machine can check and a third party can re-run, and we are starting where a single mistake is most expensive.
About and contact
Veric Systems, Inc. was founded in 2026 by Sam Gleeson. The work is done by one person directing software agents whose output is checked by the Lean proof kernel.