01

트랙

TRUST404는 4개의 지정 보안 트랙1개의 Open Security Track으로 구성됩니다. 각 트랙은 명확한 문제 정의, 필수 제출물, 평가 기준을 제공하며, 참가자는 요구사항을 충족하는 범위에서 자유롭게 문제 해결 방식을 설계할 수 있습니다.

해당 트랙의 핵심 기술을 실제로 사용하는 것이 참가 요건입니다. 완성도보다 동작을 봅니다 — 핵심 경로가 실제로 돌아가면 충분합니다.

01

스마트 컨트랙트 위협 탐지Smart Contract Threat Detection

문제 정의 서명 창에 뜬 컨트랙트가 무엇을 하는지 해석할 수 없는 사용자. 그리고 배포된 컨트랙트의 위험을 실행 전에 걸러낼 방법이 없는 지갑·dApp.
구현 목표 스마트 컨트랙트(.sol) 소스코드를 입력받아 악성 여부와 위험 패턴을 분석하는 도구를 구현합니다. CLI 또는 웹 인터페이스 어느 쪽이든 가능합니다.
필수 제출물
  • 입력.sol 파일을 입력받습니다. 복수 파일에 대한 일괄 분석 지원을 권장합니다
  • 판정 — Benign / Malicious / Uncertain 등 명확한 판정 결과를 제공합니다
  • 근거 — 위험 요소가 위치한 코드 또는 함수와 판단 근거를 함께 제시합니다
  • Machine-readable Output — 자동화된 평가가 가능하도록 JSON 등 구조화된 출력 형식을 지원해 주세요
  • 실행 방법 — 재현 가능한 실행 방법을 README에 제공해 주세요
평가 기준
  • 주최 측이 준비한 Mock 컨트랙트(정상·악성 샘플 및 비공개 테스트셋)를 정확하게 판별하는가
  • 단순 키워드 매칭이 아니라 코드의 로직 흐름과 권한 구조를 근거로 위험 요소를 식별하는가
  • 판정 근거가 타당한가 — 비정상적 권한 이전, 은닉된 자산 인출 경로 등
제공 자료 공개 샘플 컨트랙트 세트를 신청 확인 후 디스코드 채널로 배포합니다. 심사에는 공개되지 않은 별도 테스트셋을 사용합니다.
02

분산 신원 — DID & VCDID & Verifiable Credentials

문제 정의 자격을 증명하려면 신분증 전체를 넘겨야 하는 사용자. 그리고 최소한의 사실만 확인하면 되는데 과도한 개인정보를 보관하게 되는 서비스 제공자.
구현 목표 DID·VC 기반으로 필요한 사실만 증명하는 발급·검증 플로우를 구현합니다. 선택적 공개, 영지식 증명, 자격 폐기, 오프체인 프라이버시 보호 등을 다룰 수 있습니다. 예시 — DID 기반 동적 QR 인증을 통한 전자출결 및 대리 출석 방지 / DID·VC 자격 검증과 ZKP를 결합한 익명 투표 / 학회·동아리 활동 이력의 VC 기반 디지털 배지 발급.
필수 제출물 권장 구현 요소입니다.
  • Issuer / Holder / Verifier 역할 구분 — 한 화면 안이어도 되지만 역할은 구분되어야 합니다
  • End-to-End Flow — Credential 발급 → 보관 → 제시 → 검증
  • 공개 범위 인터페이스 — 검증자에게 공개되는 정보와 비공개되는 정보를 명확히 구분합니다
  • Credential Revocation — 구현 시 평가에 반영합니다
평가 기준
  • 발급 → 제시 → 검증 중 최소 한 경로가 실제로 동작하는가 (폐기까지 구현 시 가점)
  • 어떤 정보가 노출되지 않는지 구체적으로 설명할 수 있는가
  • W3C DID/VC 표준 호환 여부 — 필수는 아니나 가점
  • 캠퍼스·학회·동아리 생태계의 실재하는 문제를 다루면 「문제 정의」 항목에서 가점
제공 자료 ZKP를 직접 구현할 필요는 없습니다. 기존 라이브러리(예: Semaphore) 활용을 권장합니다. 최소 한 개의 동작하는 발급 → 검증 Flow를 요구합니다. 기획안 형태의 제출도 접수하지만, 동작하는 프로토타입을 강력히 권장하며 「동작하는 구현」 20% 항목은 실제로 동작하는 결과물이 있어야 점수를 받을 수 있습니다.
03

오프체인 의사결정 검증Verifiable Off-chain Decisions

문제 정의 거절된 요청은 트랜잭션이 되지 못해 온체인에 흔적이 없고, 기관이 자기 DB에 남긴 한 줄만이 유일한 증거인 상황. 그리고 그 한 줄을 기관이 나중에 고치거나 지워도 밖에서는 알 수 없는 구조.
구현 목표 오프체인에서 내려진 거절·승인 판단을 제3자가 독립적으로 검증할 수 있는 기록 및 검증 구조를 구현합니다.
필수 제출물
  • 거절 발생 시 신뢰 가능한 기록으로 저장되는 동작 프로토타입
  • 거절 레코드 스키마 — 무엇을 해시하고 서명하여 저장하는지
  • 제3자가 기관을 신뢰하지 않고 거절 한 건을 검증하는 독립 검증 도구
  • 시연 1 — 검증자가 기관의 서버·DB에 접근하지 않고 거절 한 건을 확인하는 흐름
  • 시연 2 — 기록이 사후에 조작·삭제·누락되었을 때 탐지되는 흐름
평가 기준
  • 불변성 — 기록이 변조되지 않거나, 변조 시 탐지되는가
  • 완전성 — 기록의 누락을 탐지할 수 있는가
  • 독립 검증 가능성 — 제3자가 기관의 서버·DB에 접근하지 않고 검증할 수 있는가
  • 부인 방지 — 요청자와 거절 주체 누구도 부인할 수 없는가
제공 자료 거절 시나리오 예시와 검증 대상 데이터 형식을 신청 확인 후 디스코드 채널로 안내합니다.
04

익스플로잇 자동 증명 에이전트Autonomous Exploit Prover

문제 정의 위험해 보인다는 데까지만 말하고 실제로 뚫리는지는 증명하지 못하는 보안 AI. 그리고 쌓인 리포트 중 무엇이 진짜 익스플로잇인지 가려낼 방법이 없는 감사 파이프라인. 그리고 그것을 가려낼 근거가 되어줄, 실제로 깨진 사례의 부재.
구현 목표 타깃 컨트랙트를 분석해 실행 가능한 Exploit PoC를 생성하고 스스로 검증하는 에이전트를 구현합니다. 타깃 컨트랙트, 불변식 세트, 실행 환경 매니페스트는 모두 주최 측이 제공합니다. 불변식은 언제나 변하면 안 되는 값입니다 — 토큰의 Total Supply가 임의로 늘어나지 않는다 같은 것.
필수 제출물
  • 입력 — 타깃 컨트랙트(.sol), 불변식 세트, 실행 환경 매니페스트를 읽어 들입니다
  • 탐색 — 코드를 분석해 공격 후보를 도출합니다. 방법은 자유입니다
  • 생성 — 후보를 실행 가능한 Exploit PoC로 변환합니다
  • Self-validation Loop — 생성한 PoC가 불변식을 위반하지 못한 경우 탐색과 생성을 반복합니다. 이 루프가 이 트랙의 핵심입니다
  • 출력 — 1회 실행으로 산출되는 결과물. PoC 코드와, 어느 불변식을 어떻게 위반했는지에 대한 설명
평가 기준
  • 생성된 PoC가 실행되어 불변식을 실제로 위반하는가 — 1순위입니다. 실행 및 재현에 실패한 PoC는 해당 평가 항목에서 점수를 받을 수 없습니다
  • 동일 조건에서 결정론적으로 재현되는가
  • 취약한 컨트랙트에서는 유효한 PoC를 생성하면서 정상 컨트랙트에서는 불필요한 Exploit 결과를 생성하지 않는가
  • 이미 공개된 익스플로잇의 재현이 아니라 에이전트가 스스로 도출한 경로인가
  • 미공개 타깃에 대한 일반화 성능과 재현 가능한 최소 PoC의 품질을 함께 평가합니다
제공 자료
  • 공개 타깃 컨트랙트 세트와 각 타깃의 불변식 세트를 신청 확인 후 디스코드 채널로 배포합니다. 타깃은 난이도를 단계적으로 구성합니다
  • 매니페스트 규격과 채점 규칙은 대회 전에 공개합니다. 심사에는 공개되지 않은 별도 타깃을 사용합니다
  • 채점 하네스와 베이스라인 에이전트는 준비되는 대로 디스코드 채널에 배포합니다
재현되는 PoC가 핵심이므로 기획안만 제출하는 형태는 이 트랙에 적합하지 않습니다. 다만 타깃 하나에 대한 유효 PoC만으로도 유효 제출로 인정합니다.
05

오픈 시큐리티 트랙Open Security Track

문제 정의 앞선 네 개 트랙에 포함되지 않는 Web3 보안·신뢰·인프라 문제. 트랙에 맞춰 문제를 고르는 대신 이미 풀고 싶은 문제를 들고 온 팀을 위한 자리입니다.
구현 목표 새로운 보안 문제와 접근 방식을 자유롭게 제안합니다. Wallet Security, Agent Payment, x402, Multichain Security 등을 환영합니다. x402나 Agent Payment도 단순 결제 서비스 제작이 아니라 권한·한도·정책 검증·공격 시나리오·감사 추적 등 보안 문제를 명확히 다루어야 합니다.
필수 제출물 동작하는 프로토타입과 함께, 아래 네 가지를 제출물이 스스로 밝혀야 합니다.
  • Threat Model — 누구를 공격자로 가정했는가. 무엇을 할 수 있고 무엇을 할 수 없는 상대인지
  • Protected Asset — 무엇을 지키는가
  • Failure Condition — 무엇이 깨지면 실패인가
  • Validation Method — 그것을 어떻게 확인했는가. 시나리오든 수치든, 실행 결과
평가 기준 공통 배점 그대로 심사합니다. 다른 트랙은 트랙별 기준이 「보안적 타당성」과 「검증 가능성」의 채점 근거로 쓰이지만, 이 트랙은 그 근거를 위 네 항목으로 제출물이 직접 제시합니다.
제공 자료 트랙 전용 자료는 없습니다. 필요한 자료가 있으면 디스코드 기술 채널로 문의해 주세요.