01

Tracks

TRUST404 runs four designated security tracks and one Open Security Track. Each track states its challenge, required deliverables and evaluation criteria; within those requirements, how you solve the problem is yours to design.

Using the track's core technology for real is an entry requirement. We look at whether it runs, not how finished it looks — one working path through the core is enough.

01

Smart Contract Threat DetectionPRE-SIGNING ANALYSIS

Challenge A user who cannot read what the contract in the signing dialog actually does. And a wallet or dApp with no way to screen a deployed contract before it executes.
Objective Build a tool that takes Solidity (.sol) source and analyses it for malicious behaviour and risk patterns. A CLI or a web interface both work.
Required Deliverables
  • Input — accepts .sol files. Batch analysis of multiple files is recommended
  • Verdict — a clear result such as Benign / Malicious / Uncertain
  • Evidence — the code or function where the risk sits, together with the reasoning behind the verdict
  • Machine-readable output — a structured format such as JSON, so evaluation can be automated
  • Run instructions — a reproducible way to run it, in the README
Evaluation Criteria
  • Accuracy against the organisers' mock contracts — benign and malicious samples, plus a held-out test set
  • Whether risk is identified from the logic flow and permission structure rather than keyword matching
  • Whether the reasoning holds up — unusual ownership transfer, hidden withdrawal paths and the like
Resources A public sample contract set is distributed through the Discord channel once your application is confirmed. Judging uses a separate, unpublished test set.
02

DID & Verifiable CredentialsSELECTIVE DISCLOSURE

Challenge A user who has to hand over a whole ID document to prove one fact. And a service provider left holding far more personal data than it needed to check.
Objective Build an issuance and verification flow on DID and VCs that proves only what needs to be known. Selective disclosure, zero-knowledge proofs, revocation and off-chain privacy are all in scope. For example — DID-based rotating QR check-in that prevents proxy attendance; anonymous voting combining VC verification with ZKP; VC-based digital badges for society and club activity records.
Required Deliverables
  • Issuer / Holder / Verifier separation — they can live in one interface, but the roles must be distinct
  • End-to-end flow — credential issued → held → presented → verified
  • Disclosure interface — makes clear what the verifier sees and what it does not
  • Credential revocation — counts toward evaluation where implemented
Evaluation Criteria
  • Whether at least one path actually runs — issue, present or verify (revocation adds credit)
  • Whether you can state precisely which information is never exposed
  • W3C DID/VC conformance — not required, but credited
  • Addressing a real problem in campus, society or club life earns credit under Problem Definition
Resources You do not need to implement ZKP yourself. Existing libraries such as Semaphore are recommended. At least one working issue → verify flow is required. Concept submission is accepted, but a working prototype is strongly recommended and is required to receive the Implementation score.
03

Verifiable Off-chain DecisionsDECISION PROVENANCE

Challenge A rejected request never becomes a transaction, so it leaves no on-chain trace — the single line in the institution's own database is the only evidence there is. And if that line is later edited or deleted, nobody outside can tell.
Objective Build a record and verification structure that lets a third party independently verify approval and rejection decisions made off-chain.
Required Deliverables
  • A working prototype that stores each rejection as a trustworthy record
  • The rejection record schema — what gets hashed, signed and stored
  • An independent verification tool a third party can use without trusting the institution
  • Demo 1 — a verifier confirming one rejection without access to the institution's servers or database
  • Demo 2 — detection when a record is later altered, deleted or omitted
Evaluation Criteria
  • Immutability — records cannot be altered, or alteration is detectable
  • Completeness — omissions can be detected
  • Independent verifiability — verification works without access to the institution's systems
  • Non-repudiation — neither the requester nor the decision-maker can deny it
Resources Example rejection scenarios and the data formats to verify are shared through the Discord channel once your application is confirmed.
04

Autonomous Exploit ProverPROOF, NOT SUSPICION

Challenge Security AI that gets as far as "this looks risky" and stops short of proving it. Audit pipelines with no way to tell which of the stacked reports is a real exploit. And no body of actually-broken cases to tell them apart with.
Objective Build an agent that analyses a target contract, generates a runnable exploit PoC and validates it itself. The target contracts, invariant sets and execution manifests are all provided by the organisers. An invariant is a value that must never change — a token's total supply not increasing arbitrarily, for instance.
Required Deliverables
  • Input — reads the target contract (.sol), the invariant set and the execution manifest
  • Search — analyses the code and derives attack candidates. The method is up to you
  • Generation — turns a candidate into a runnable exploit PoC
  • Self-validation loop — where the generated PoC fails to violate an invariant, search and generation repeat. This loop is the heart of the track
  • Output — one artefact from one run: the PoC and an account of which invariant it violated and how
Evaluation Criteria
  • Whether the generated PoC runs and actually violates an invariant — first priority. A PoC that fails to execute or reproduce scores nothing on this criterion
  • Whether results reproduce deterministically under the same conditions
  • Whether it produces valid PoCs on vulnerable contracts without producing spurious exploit results on sound ones
  • Whether the path was derived by the agent rather than reproducing a publicly known exploit
  • Generalisation to unpublished targets and the quality of a reproducible minimal PoC, evaluated together
Resources
  • A public target contract set with each target's invariant set, distributed through Discord once your application is confirmed. Targets are graded by difficulty
  • Manifest specification and scoring rules are published before the event. Judging uses separate, unpublished targets
  • The scoring harness and a baseline agent are posted to the Discord channel as they are ready
A reproducing PoC is the point, so concept-only submissions do not fit this track. A valid PoC against a single target is enough to count as a submission.
05

Open Security TrackBRING YOUR OWN PROBLEM

Challenge A Web3 security, trust or infrastructure problem that none of the four tracks above covers. For teams who arrived with a problem rather than picking one to fit a track.
Objective Propose your own security problem and approach. Wallet security, agent payment, x402 and multichain security are all welcome. x402 and agent payment count here as security work, not as payment products — the submission has to address authorisation, limits, policy validation, attack scenarios or audit trails explicitly.
Required Deliverables A working prototype, plus these four stated by the submission itself.
  • Threat model — who the attacker is, and what they can and cannot do
  • Protected asset — what is being defended
  • Failure condition — what counts as broken
  • Validation method — how you confirmed it. Scenarios, numbers, or the output of a run
Evaluation Criteria Judged on the common scoring, unchanged. For the other tracks, the track's own criteria supply the basis for Security Soundness and Verifiability; here the four items above supply it.
Resources No track-specific resources. If you need something, ask in the Discord technical channel.
Apply now -> Rules -> Back to overview