Scanning the worker SBT contracts before anything mints
A short companion to this week's Round 1 note. A static-analysis pass over the worker soulbound-token contracts came back with zero High or Medium findings in our own code — and the more useful part is how to read that report without overclaiming from it.
The main achievement this week was the gateway going green and dark. This is the smaller, related one: before any on-chain identity for workers gets deployed, the contracts behind it got a static-analysis pass. The result is clean, but I'd rather explain how to read it than just wave the word "clean" around — because a scanner report is exactly the kind of artifact that's easy to overstate.
What we ran
The two contracts are the worker soulbound tokens — non-transferable on-chain badges tied to a worker identity. One is DCS-branded (DCSWorkerSBT); the other sits at the token/network layer (TRDWorkerSBT_v2). We ran Slither 0.11.5 against solc 0.8.28 over both.
The headline: zero High or Medium findings in the custom code. The report does surface High/Medium entries, but every one of them lands in OpenZeppelin's Math.sol — the standard library both contracts import — and reads as a known false-positive pattern, not something in code we wrote. The only finding actually attributable to our code is a benign Low-severity reentrancy note in mint(), of the kind that's expected and non-exploitable in this shape.
A scanner that returns findings you have to interpret is more trustworthy than one that returns a green checkmark. The interpretation is the work.
The decision it drove
The scan also settled a design choice. There are two lineages of the contract: a v1 built on OpenZeppelin's Ownable (a single owner key) and a v2 built on AccessControl (named roles). We're deploying the v2 / AccessControl version, not v1. Role-based access is the right posture for anything that might one day gate real worker identity, and the scan gave us the clean base to commit to it. The full findings live in an internal report (WEB3_SCAN_RESULTS_2026-07-01.md).
The scan, in one line
- ToolSlither 0.11.5 · solc 0.8.28
- ContractsDCSWorkerSBT · TRDWorkerSBT_v2
- Custom-code High/Med0
- Only own-code findingbenign Low reentrancy in mint()
- Deploy targetv2 / AccessControl
What this is not
A static scan is not a full audit. Slither is automated static analysis re-run internally by us; it catches known patterns, not everything. A clean Slither pass is a floor, not a certificate, and it isn't a substitute for a third-party review before anything of value depends on these contracts.
Nothing is deployed to mainnet on the strength of this. The scan clears the code to move forward; it does not mean the worker SBTs are live or minting. Money and autonomy stay dark, in line with the rest of this week's work.
OpenZeppelin's flagged entries are library false-positives. We're reporting zero High/Medium in custom code specifically — the OZ Math.sol hits are a known scanner artifact, and we're not claiming to have re-audited OpenZeppelin itself.
Small week for this thread, but it's the kind of pre-flight check that's worth doing quietly before it ever matters loudly. When these contracts get closer to a real deployment, the next honest entry will say who signed off and what a deeper review found.
— Deepak
Follow the build
Read the main note on Round 1 — deployed, green, and dark on purpose.