Trustblock: public smart contract audits, as data

Try any project or contract in the card playground: it shows both cards and their JSON. Two routes answer the question a block explorer asks on a contract page: has the project behind this address been audited, and is anything still open? The Etherscan card returns display strings, an image and a colour. The Blockscout card returns the same facts as counts, for a renderer that writes its own wording. Both routes take your API key as a bearer token and consume no API credit.

Request

Name the contract with chain and address, or the project with slug or domain. chain and address go together: one without the other answers 400.

curl "https://api.trustblock.run/v1/project/etherscan-card?chain=1&address=0xcc4304a31d09258b0029ea7fe63d032f52e44efe" \
  -H "Authorization: Bearer $TRUSTBLOCK_API_KEY"

chain is one of the names on Supported chains, or a decimal EVM chain id: chain=1 and chain=ethereum return the same card. A chain Trustblock does not record answers 200 with no card, never an error, so an explorer can send every chain it serves.

The five cards

The worst state wins, in this order. “Open” means neither fixed nor acknowledged, across every audit still in force.

State	Etherscan `centerText`	`statusColor`	Blockscout
Incident	”Exploited 24 May 2026” (or “Key compromise”, “Front-end attack”, “Rug pull”)	`#E84353` red	`activeRektsNumber` > 0
Open critical	”2 open critical findings”	`#E84353` red	`activeCriticalIssuesNumber` > 0
Acknowledged critical	”1 critical acknowledged, not fixed”	`#F08D3C` orange	`acknowledgedCriticalIssuesNumber` > 0
None open	”No open critical findings”	`#67A22F` green	all three are 0
No audit	”No audit on Trustblock”	`#F08D3C` orange	`isFound: false`

An incident stays on the card while it is later than the latest audit in force, or less than twelve months old. The first four come with isFound: true. The last comes with isFound: false: the project is unknown, has no audit, or the chain is not one Trustblock records. The Etherscan card also sends status, the same value as isFound, for templates that hide the card on status: false.

The contract line

When the request names a contract and an audit’s own scope names that address, both cards add contractLine:

{
  "isFound": true,
  "status": true,
  "centerText": "No open critical findings",
  "statusColor": "#67A22F",
  "contractLine": "This address was in the scope of 2 audits; latest: Hacken, 8 May 2026",
  "topRightText": "Last audit May 2026",
  "centerText2": "2 audits by 1 firm"
}

When no audit’s scope names the address, the field is absent (not null) and the card describes the project as a whole. A renderer that ignores contractLine shows exactly what it showed before.

The Blockscout card

Field	Meaning
`isFound`	`false` for the no-audit card; the response is then `isFound` and `extra` only.
`auditsNumber`	The project’s audits on Trustblock.
`auditors`	The names of the firms that audited the project.
`activeCriticalIssuesNumber`	Open Critical findings in the audits in force.
`activeHighIssuesNumber`	Open High findings, reported beside the Critical count, not merged into it.
`acknowledgedCriticalIssuesNumber`	Critical findings acknowledged without a fix. Not part of the open count.
`activeRektsNumber`	Incidents shown on the card.
`latestRektAt`	Milliseconds since the Unix epoch for the latest of them, or `null`.
`isAIScan`	Whether the latest audit is an AI scan.
`contractLine`	As above.

Errors and caching

A missing project and a failure are different answers. “No audit” is a 200 and is meant to be rendered. When the lookup itself fails, the route answers 503 if a dependency was briefly unreachable (with Retry-After, in seconds) or 500 otherwise. Neither says anything about the project, so neither should be cached as a card.

Status	Meaning
`200`	A card: found, or the no-audit card.
`400`	The query is unusable, for example `chain` without `address`.
`401`	No `Authorization` header.
`403`	The key is not recognised.
`500`	The lookup failed.
`503`	Briefly unavailable; retry after `Retry-After` seconds.

A lookup by chain and address may be answered from a cache for up to five minutes, so a new audit or a correction reaches the card within that time. The full request and response schemas are in the Etherscan card and Blockscout card references.

Guides

Explorer cards

Request

The five cards

The contract line

The Blockscout card

Errors and caching

​Request

​The five cards

​The contract line

​The Blockscout card

​Errors and caching

Request

The five cards

The contract line

The Blockscout card

Errors and caching