hackquest logo

veto

Pre-signature verification for autonomous agents. VETO simulates transactions on X Layer, diffs intent against effect, and refuses the signature before the loss. Agents propose. VETO disposes.

视频

项目图片 1
项目图片 2
项目图片 3
项目图片 4

技术栈

Next
Web3
Ethers
Node
Solidity
Typescript
Fastify
viem

描述

VETO - The Last Word Before the Chain

Every autonomous transaction is signed in the dark. An agent holds a wallet, receives a task, and signs. No eyes, no doubt, no appeal. The chain does not forgive. The only moment a mistake can be caught is the moment before the signature. VETO owns that moment.


What VETO does:

An agent sends VETO an unsigned transaction plus what it believes the transaction does. VETO forks X Layer at the current block, executes the exact transaction, extracts the real state changes, and diffs stated intent against simulated reality.
If intent and effect agree: ALLOW. The agent signs.
If a soft threshold is crossed: WARN. The agent signs with a flag.
If an undeclared effect is found: VETO. Signature refused.

Every ruling ships a hash-committed evidence bundle and an attestation written to X Layer. VETO never asks to be believed. Any verdict can be independently re-derived and checked on-chain.

Why this matters:

Wallet popups and token scanners assume a human is looking. Autonomous agents execute inside a loop where no one is. A transaction can pass every safety check and still be wrong, because no existing tool compares what the agent intended against what the transaction actually does. VETO is the first layer that performs that comparison.


The engine - five instruments, one core:

1. /verdict - Pre-signature verdict. Is this transaction safe to sign right now?

2. /approvals - Approval hygiene. Which live allowances expose this wallet to a drain?

3. /payload - Task-payload screening. Is this inbound job trying to inject or drain?

4. /counterparty - Counterparty check. Can this address be trusted before engagement?

5. /forensics - Post-incident forensics. What should have been caught?

Policy profiles:

Callers set a risk posture. The same transaction returns ALLOW under one profile and VETO under another.

- treasury-strict: No approvals. 1% slippage cap. Registered ledger only.

- standard: Bounded approvals. 3% slippage. Denylist screened.

- degen-loose: Approvals allowed. 8% slippage. Warnings only.

Rule pipeline:

- intent-divergence: Does the transaction do what the agent said?

- approval-risk: Does it grant token approvals the agent didn't declare?

- counterparty: Is the recipient address on the drainer registry?

- honeypot: Can the received token be sold, or is the agent trapped?

- slippage: Does the trade exceed the policy's acceptable loss?


Request flow:

agent                 engine                    x layer
    |                      |                          |
    |  POST /verdict       |                          |
    | -------------------> |                          |
    |                      |                          |
    |    402 + challenge    |                          |
    | <------------------- |                          |
    |                      |                          |
    |  settle USDT on chain|                          |
    | -------------------> |                          |
    |                      |                          |
    |                      |  fork at latest block    |
    |                      | -----------------------> |
    |                      |                          |
    |                      |  simulate transaction    |
    |                      | -----------------------> |
    |                      | <---- state diff ------- |
    |                      |                          |
    |                      |  run 5-rule pipeline     |
    |                      |  aggregate verdict       |
    |                      |                          |
    |                      |  write attestation       |
    |                      | -----------------------> |
    |                      | <---- tx hash ---------- |
    |                      |                          |
    |  verdict + evidence  |                          |
    | <------------------- |                          |
    |                      |                          |

Three consumption paths:

1. Marketplace (A2MCP) - Listed on OKX.AI. Any agent pays per verdict in USDT via x402. The payment is the auth.

2. SDK middleware - guard(signer) wraps any agent signer. Ten lines. A red verdict refuses to sign by design.

3. Always-on watch - Register wallets for continuous monitoring and attestation.

Proof:

- Attestation contract live on X Layer mainnet

- Engine API live and gated with x402 pay-per-call

- Frontend deployed with verdict console and dashboard

- OKX.AI Agent #5165: https://www.okx.ai/agents/5165

- GitHub: https://github.com/0xkinno/veto


Verdict engine instruments

Endpoint

Instrument

What it answers

USDT/call

/verdict

Pre-signature verdict

Is this transaction safe to sign right now?

0.15

/counterparty

Counterparty check

Can this address be trusted before I engage?

0.10

/payload

Task-payload screening

Is this inbound job trying to inject or drain?

0.20

/approvals

Approval hygiene

Which live allowances expose this wallet?

0.30

/forensics

Post-incident forensics

What should have been caught in this tx?

0.50

Policy profiles

Profile

Approval cap

Slippage ceiling

Recipient rule

treasury-strict

Denied

1.0%

Registered ledger only

standard

Bounded

3.0%

Denylist screened

degen-loose

Allowed

8.0%

Warnings only


Repo Structure

veto/
├── .github/workflows/
│   ├── ci.yml                   # CI: typecheck + test
│   └── codeql.yml               # CodeQL security scanning
├── apps/
│   ├── engine/                  # verdict engine (Node, TypeScript, Fastify)
│   │   └── src/
│   │       ├── __tests__/       # vitest test suite
│   │       ├── simulator/       # X Layer fork simulation
│   │       ├── diff/            # state-diff extractor
│   │       ├── intent/          # intent parser
│   │       ├── rules/           # 5 pluggable rule modules
│   │       ├── evidence/        # evidence bundle + keccak256 hashing
│   │       ├── x402/            # pay-per-call gate (OKX Facilitator)
│   │       ├── routes/          # HTTP endpoints
│   │       └── lib/             # shared types + config
│   └── web/                     # Next.js 14 (landing + console + dashboard)
├── packages/
│   └── sdk/                     # guard(signer) middleware
├── contracts/                   # Solidity 0.8.24 + Hardhat
├── docs/
│   ├── screenshots/             # product screenshots
│   └── CHECKLIST.md             # build phase tracker
└── design/                      # hero + hands assets

Tech stack:

- Engine: Node 20, TypeScript, Fastify

- Simulation: viem, X Layer fork (eth_call + debug_traceCall)

- Payments: x402 (exact + EIP-3009) via OKX Facilitator, USDT on X Layer

- Contract: Solidity 0.8.24, Hardhat

- Frontend: Next.js 14, Lenis, GSAP

- Deploy: Vercel (web), Render (engine)

Built for the OKX AI Genesis Hackathon.

本次黑客松进展

Phase 1-2:

Project scaffold, monorepo setup, attestation contract (Solidity 0.8.24), Hardhat config for X Layer, type system for verdicts and evidence bundles.

Phase 3:

Attestation contract deployed to X Layer testnet, then redeployed to mainnet. Same deployer, same nonce, deterministic address on both chains. Contract verified on-chain.

Phase 4:

Verdict engine core. Fork simulator using viem with X Layer RPC. State-diff extractor. Intent parser. Five-rule pipeline (intent-divergence, approval-risk, counterparty, honeypot, slippage). Evidence bundle hashing with keccak256. Verdict aggregator producing ALLOW/WARN/VETO decisions.

Phase 5:

x402 payment integration. OKX Facilitator wired for verify and settle. EIP-3009 exact scheme. PAYMENT-REQUIRED challenge header with base64-encoded JSON (x402Version, resource, accepts with scheme, network, asset, amount, payTo, maxTimeoutSeconds). Per-call pricing across five instruments (0.15-0.50 USDT).

Phase 6:

Frontend build. Next.js 14 landing page with cinematic hero, floating verdict cards, capabilities section, exhibit section, and integration code samples. Verdict console with preset scenarios (clean swap, undeclared approval). Dashboard with verdict trends, distribution, risk timeline, latency charts, and recent verdicts feed.

Phase 7:

OKX.AI ASP registration. Agent #5165 listed. Avatar spec compliance (440x440, square corners). x402 header fix for listing review. Engine deployed to Render. Frontend deployed to Vercel.

Final:

CI and CodeQL GitHub Actions workflows. Product screenshots in repo. README polished with all live links, proof table, and badges.

融资状态

No external funding. Solo-built during the hackathon period.
Infrastructure costs covered by me using; Vercel for frontend, Render for engine API.

队长
KKingsley Ojilere
项目链接
部署生态
X Layer MainnetX Layer Mainnet
赛道
InfraAI