Sentinel

Sentinel is an ERC-8004 trading agent built for the AI Trading Agents hackathon. The project is now optimized for Best Validation & Trust Model and Best Compliance & Risk Guardrails rather than raw PnL, and it is configured for the official shared Sepolia judging contracts.

Public website

Sentinel’s public submission surface is split in two:

• homepage / pitch site: https://sentinel.chequemate.space/
• live proof dashboard: https://sentinel.chequemate.space/dashboard

The homepage is the judge-facing narrative. The dashboard is the verification layer behind that narrative.

Judge path in 2 minutes

If you only have two minutes, this is the fastest way to evaluate Sentinel:

1. Open the dashboard and inspect the latest checkpoint, veto, or halt.
2. Click a checkpoint row and verify the EIP-712 signature locally in the browser.
3. Run npm run verify-checkpoints to reconcile the local checkpoint log with on-chain attestations.
4. Run python scripts/demo_halt.py to force a signed kill-switch halt and watch the new artifact appear locally and on-chain.

The core claim is simple: Sentinel does not ask judges to trust our presentation. It gives them enough structured evidence to verify what happened, why it happened, and what risk controls refused to allow.

Official judging infrastructure

Sentinel now targets the official shared Sepolia ERC-8004 stack used by the leaderboard:

• AgentRegistry: 0x97b07dDc405B0c28B17559aFFE63BdB3632d0ca3
• HackathonVault: 0x0E7CD8ef9743FEcf94f9103033a044caBD45fC90
• RiskRouter: 0xd6A6952545FF6E6E6681c2d15C59f9EB8F40FdBC
• ReputationRegistry: 0x423a9904e39537a9997fbaF0f220d79D7d545763
• ValidationRegistry: 0x92bF63E5C7Ac6980f237a7164Ab413BE226187F1

Network:

• Sepolia Testnet
• Chain ID 11155111

Old self-deployed Base Sepolia artifacts are historical only and are not part of the judging path.

What judges can verify

• Every decision is written to checkpoints.jsonl as a tamper-evident hash chain.
• Every checkpoint is signed with EIP-712 by the agent wallet.
• Actionable artifacts such as trades, exits, vetoes, halts, and scheduled heartbeats are posted to the on-chain ValidationRegistry.
• The dashboard lets a third party inspect the raw structured checkpoint, see the signature, and verify the signature locally in-browser.
• The verifier CLI lets anyone reconcile local checkpoints with on-chain attestations.

ERC-8004 usage

Sentinel’s canonical identity is the shared-registry agentId assigned on Sepolia. That identity is tied to the agent wallet and used in three ways:

• AgentRegistry anchors the persistent ERC-8004 identity.
• RiskRouter acts as the on-chain gate before trade execution.
• ValidationRegistry stores signed checkpoint attestations for public verification.

The identity layer is not decorative. Sentinel uses it to compute a deterministic trust score that can:

• allow a trade at full size
• reduce the trade to 50% size
• block the trade and emit a signed trade_veto checkpoint

What is signed, what is on-chain, what stays local

Signed with EIP-712:

• signal checkpoints
• executed trades
• exits
• vetoes
• halts
• heartbeats

Anchored on-chain:

• trades
• exits
• trade vetoes
• kill-switch halts
• scheduled heartbeats

Stored locally for replay and verification:

• market data provenance
• model state and indicator snapshot
• compliance checks
• execution metadata
• position state before and after the decision

Trust model

Sentinel’s trust score is deterministic and reproducible:

trust_score =
  0.10 * identity_age
  + 0.20 * registration
  + 0.20 * checkpoint_integrity
  + 0.15 * provenance
  + 0.10 * attestation
  + 0.15 * risk_health
  + 0.10 * consistency

Trust gate behavior:

• < 0.50: block trade and emit signed trade_veto
• 0.50 <= score < 0.65: allow trade at 50% size
• >= 0.65: allow full trade size

See docs/trust-model.md for the full model and lifecycle.

Risk and compliance behavior

Sentinel’s guardrails are part of the artifact trail, not just hidden code:

• every validate_trade call produces structured compliance checks
• every veto records why the trade was refused
• every halt writes a signed halt checkpoint with the breached metric and configured limit
• scheduled heartbeats prove the agent is still alive even when it does not trade

The dashboard exposes drawdown, daily-loss headroom, trust-gate state, recent vetoes, and recent halts without needing shell access.

Dashboard

Run the judge-facing dashboard:

source venv/bin/activate
python dashboard/app.py

The dashboard includes:

• Trust Score
• Risk Monitor
• Checkpoint Explorer
• Verification
• Compliance Events
• Heartbeat Anchors
• a static Judge Path panel so reviewers can follow the intended verification flow quickly

Public routing:

• / → submission homepage
• /dashboard → live verification dashboard

Suggested README screenshots

Use 3 screenshots only. More than that usually dilutes the story.

1. Dashboard overview Capture the full top section showing Trust Score, Verification, Judge Path, and Risk Monitor. What it proves: Sentinel is framed around trust, validation, and guardrails from the first screen.

2. Checkpoint detail modal Open a recent actionable checkpoint and capture decisionContext, verification details, marketData, and compliance. What it proves: the decision artifact is structured, signed, and inspectable.

3. Compliance halt or veto Capture a fresh halt or trade_veto event in Compliance Events and the Checkpoint Explorer. What it proves: the guardrails are active, visible, and auditable rather than hidden in logs.

When taking screenshots:

• prefer data-rich states over empty dashboards
• keep the browser width wide enough to show multiple trust/compliance panels at once
• avoid terminal clutter in README screenshots; terminal output belongs in the demo video instead

Verifier CLI

Install Node dependencies:

npm install

Run the verifier:

npm run verify-checkpoints

For a full-history audit instead of the fast recent-window default:

npm run verify-checkpoints -- --all

The verifier checks:

• hash-chain integrity
• EIP-712 signature validity
• on-chain attestation presence for actionable checkpoints
• best-effort market replay for recent Kraken-backed checkpoints

It exits non-zero only if signature verification or hash-chain verification fails.

Typical judge flow:

npm run verify-checkpoints -- --limit=20

That fast path validates the most recent actionable artifacts first. Use --all only when you want a full-history sweep.

Quick start

Create and activate the Python environment:

python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Register on the official shared AgentRegistry first:

python scripts/register_agent.py

Run a single safe iteration:

python -m agent.main --once --execution disabled

Run the agent continuously in paper mode:

python -m agent.main --execution paper

Open the dashboard locally at:

http://127.0.0.1:5001

Run one smoke trade:

python -m agent.main --execution paper --smoke-trade --smoke-symbol BTCUSD

Trigger a deterministic halt demo:

python scripts/demo_halt.py

Optional vault claim helper:

python scripts/fund_agent.py

Kraken submission update

The hackathon submission form now also expects:

• your read-only Kraken API key
• your Kraken account ID / username

Docs

• docs/trust-model.md
• docs/demo-script.md
• docs/hackathon-brief.md

Prize alignment

• Best Validation & Trust Model: deterministic trust scoring, replayable checkpoints, browser-side signature verification, CLI reconciliation with on-chain attestations
• Best Compliance & Risk Guardrails: signed vetoes, signed halts, visible guardrail checks, scheduled heartbeats, and a kill-switch demo that produces auditable artifacts instead of silent failure

Next step intentionally deferred

IPFS checkpoint snapshotting is intentionally deferred in this phase. The checkpoint schema is already structured so a future CID can be attached without breaking replay or verification flows.