Verifying a certificate without us

A certificate lives on the issuer's own smart contract, keyed by its name. Its link (the one in its QR code) already carries everything needed to read it: the contract address, the abi of the one function or event that holds it, the certificate name as topic or params, and for events the from_block it was written in.

If the link has topic — the default — the certificate was written as an ItemDataLog event. Ask any Ethereum node for the contract's logs, filtered on the event and on the keccak-256 hash of the certificate name (for example cast keccak "<CERTIFICATE_NAME>"):

curl -s <RPC_URL> -H 'Content-Type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1, "method": "eth_getLogs",
  "params": [{
    "address": "<CONTRACT_ADDRESS>",
    "fromBlock": "<FROM_BLOCK as hex, e.g. 0xb2cb60>",
    "toBlock": "latest",
    "topics": [
      "0x0b6eca9a1ccc73ec5b3c716b329bd678aa7eb09c3f189e46c22b80359fa2ee7c",
      "<KECCAK_OF_CERTIFICATE_NAME>"
    ]
  }]
}'

The first topic is the hash of the event signature ItemDataLog(string,string,uint256). Each log's data is the ABI-encoded pair (string certificate, uint256 timestamp); the most recent log is the current version, and the timestamp is when the chain recorded it. Many providers limit one request to about 10,000 blocks — if yours refuses the range, set toBlock to fromBlock + 9,999 and step forward.

If the link has params, the certificate is stored in a variable. Call the getter named in the link's ABI:

# with cast (foundry), against any Ethereum RPC endpoint
# contracts deployed up to template V1_2_0:
cast call <CONTRACT_ADDRESS> "getCert(string)(string)" "<CERTIFICATE_NAME>"

# contracts deployed from template V1_2_2 onwards:
cast call <CONTRACT_ADDRESS> "ItemDataRead(string)(string)" "<CERTIFICATE_NAME>"

The reader's “Request Summary” panel shows the exact ABI, parameters and link used for any certificate you open.

When an issuer passes our identity check, we write the agreed legal name onto a single public registry contract — as a stored variable, so it is readable from any node without special log-serving infrastructure. The key is the address of the contract being verified, and the value is the legal name.

No registry has been deployed on this environment yet, so no contract carries a verified issuer name.

Both reads above are plain calls against the blockchain. Nothing in the answer comes from Transparium at the time you ask, so you do not have to trust this website — only the chain, and our claim (recorded on it) about who an issuer is.

What we assert is narrow and worth stating plainly: that we checked the identity of the organization operating a contract. We do not assert that the contents of any certificate are true — only the issuer does.