Live · eslam-x.github.io/coreguard
CoreGuard doesn't tell you whether a transaction looks safe. It produces independently verifiable evidence of whether execution conformed to what was authorized.
The official brand page — docs/BRAND.html · صفحة الهوية الرسمية: the shield, lockups, the audited color system (Core Orange #FF8A00 · Deep Core #0B0F14 · Graphite #4A5568 · Ice White #F5F7FA), the official gradient, the mark law, and the full downloadable asset kit.
- Trust gate — investor portal · بوابة الثقة: docs/TRUST.md — the live Core Mainnet anchor (chainId 1116), the independent-verify ladder, the evidence matrix, and what we never claim.
- Legal node · العقدة القانونية: LICENSE.md — MIT code, brand-and-trademark posture, bilingual.
- CoreGuard Labs — the evidence lab · مخبر الأدلة: docs/LABS.md — independent re-derivation, reviewer kits, incubation/program evidence packs.
- Verify bot (Telegram/Discord) · بوت التحقق: docs/VERIFY-BOT.md — committed engineering spec, honest PLAN_ONLY status.
Seven brand plates, each minted from ONE committed file that exclusively owns its surface — Execution Firewall, Verifier X3, Stellar Agent, Trinity, the CG-BDG/1 engine, the CGEP/1 receipt, and the Core Mainnet anchor. Every plate's artwork names its source and carries that file's full sha256 digest in a machine payload; the audit re-derives every digest from the committed tree, offline, and fails loudly on any drift — a plate can never silently drift from the bytes it certifies:
node scripts/badge-wall.mjs --audit # re-derive all 7 plate digests from the committed tree (CG-WALL/1, offline)
node scripts/badge-wall.mjs # regenerate plates + the composed wall after source changes
``` *Off-chain engine · Solidity registry · CGEP/1 draft spec. Real Core Mainnet execution verified · on-chain anchor live on Core (chainId 1116) · VERIFIED ANCHOR INTEGRITY — CoreGuard Verify · Protect · Empower*
</div>
---
## The Killer Ladder — seven rungs, pinned per ecosystem · سلّم المنتجات القاتلة
Every ecosystem entry — Core DAO · Stellar · Pi Network — pins the same seven rungs against committed evidence in its own facts file, no prose claims. The unified view:
| Rung | What it closes, on every network |
|---|---|
| **Killer Feature** | Intent-to-Evidence Binding — every intent carries tamper-evident, replayable evidence; break the binding and verification fails closed |
| **Killer Use** | AI Agent Payment Gate — agent proposals verified against policy + deterministic replay BEFORE submission; VERIFIED only, never auto-pay |
| **Killer On-Chain** | Per-network Commitment Anchor — Core anchor live on chainId 1116 · Soroban/Pi anchors carried honestly as DRY_RUN/PLAN_ONLY, never styled as live |
| **Killer Utility** | Universal DApp Shield — wrap ANY app action (swap, lend, borrow, bridge, vote); ALLOW/DENY/HOLD with a verifiable commitment |
| **Killer Adoption** | One-line integration across wallets, DEXs, contracts and AI agents of each ecosystem |
| **Killer Reference** | Deterministic replay-before-submit: audit trail + replayHash + diff + report, re-runnable by anyone |
| **Killer Customer** | Named per network — Core: DeFi, DApps, wallets, AI agents, validators, escrow/A2A · Stellar: Freighter, Soroban DEXs, agents · Pi: Browser DApps, Pi Wallet, Pi Commerce, bridges |
One ladder, three ecosystems, one Trinity view: [Core DAO](docs/COREDAO-KILLER-FEATURES.md) · [Stellar](docs/STELLAR-KILLER-FEATURES.md) · [Pi Network](docs/PI-KILLER-FEATURES.md) · [Trinity](docs/TRINITY-CORE-STELLAR-PI.md).
## Proof-first: run it, don't trust it
The agent-economy primitives run with zero keys and zero money:
- **Live playground:** [PLAYGROUND.html](https://eslam-x.github.io/coreguard/PLAYGROUND.html) — open a job, lock escrow, carve shares, reserve before signing, deliver evidence, and watch ACCEPTED / REJECTED / UNKNOWN.
- **Terminal demo:** the same cycle in one command, ending with `UNKNOWN → HELD`.
- **Architecture:** [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) — `agreed → executed → proven`, and why `UNKNOWN` stays held.
- **Facts only:** [docs/ONE-PAGER.md](docs/ONE-PAGER.md).
```bash
node demo.mjsReal code, not slides:
packages/budget/ledger.mjs ·
packages/acceptance/index.mjs ·
packages/x402/index.mjs ·
packages/job-integration/index.mjs ·
packages/refusal-audit/index.mjs
Every protocol, SDK, dispute layer, job-economy primitive, integration surface and service that exists in this repository, with its honest status (SHIPPED / LIVE / DRY_RUN / GATED / RESEARCH), is listed in one place:
- docs/ALL-IN-ONE-CATALOG.md — EVERYTHING:
all 38 packages, all 70 npm scripts, all workflows, all examples/templates,
all HTML surfaces, and a complete file index of every file in the repo (no
node_modules/.git), with paths and runnable commands. - docs/PRODUCTS.md — curated complete catalog, each row mapped to a committed path or an executed command.
- docs/PRODUCTS.html — the bilingual (AR/EN) catalog page.
Nothing in these catalogs claims revenue, customers, partners, funding, a price, a
third-party badge issuance, a live external integration or a third-party audit. Those stay
UNKNOWN / GATED until a named event with evidence exists.
CoreGuard is now a stack of sealed protocols: each layer consumes the previous layer's pinned output, re-verifies it, and never rewrites it.
CGEP/1 execution truth — intent/policy → commitment → receipt → verifier → anchor
│ (live on Core Mainnet 1116; on-chain anchor VERIFIED)
└─► EVP/1 evidence labels — consent tri-state (FULL/PARTIAL/UNKNOWN), never a
│ boolean; evidenceStatus/actualStatus split; SHA-256 pins
└─► ADAL/1 dispute package — positions, closure window, award slot
│ UNKNOWN-by-design, escrow reference-only, adapter NOT_BUILT
├─► Adapters structural mapping onto documented tribunal surfaces
│ (People's Court Partner API v2 + x402) — offline dry-run,
│ credential-gated, network-call NOT_PERFORMED
├─► Reference tribunal local synthetic adjudicator + mock escrow,
│ fail-closed settlement semantics (no funds, no broadcast)
└─► Conformance per-stage PASS / FAIL / UNKNOWN / NOT_BUILT /
NOT_AUTHORIZED suite (CI-pinned)
+ SDK + CLI surfaces (guard.*, verify*, evidence/dispute packages)
| Layer | Standard | Artifacts |
|---|---|---|
| Execution truth | CGEP/1 | receipt, verifier, anchor, packages/ (SDK/CLI/guard) |
| Evidence labels | EVP/1 | scripts/make-evidence-package.mjs (EVP_OK, 11/11), committed fixture pairs |
| Dispute package | ADAL/1 | scripts/make-dispute-package.mjs (DP_OK, 25-check verifier), reference-A/B |
| Adapter (dry-run) | @coreguard/peoples-court-adapter |
npm run peoples-court:prepare, schemas, dry-run fixtures |
| Reference tribunal | examples/reference-tribunal | sim-tribunal + mock-escrow (synthetic, fail-closed) |
| Conformance | integration-surface-map | test/delivery/interop-conformance.test.mjs |
| Article | The Missing Verification Layer for Agentic Disputes | publish-ready drafts (X thread, LinkedIn) |
The stack's boundary promise: execution, consent, adjudication, and settlement authority are four different layers. CoreGuard pins the first two, freezes the record for the third, and maps (without executing) toward the fourth. Every artifact refuses to claim more — see the adapter and tribunal honesty notes.
# the full evidence→dispute→tribunal-ready path, offline and deterministic
npm run evidence-package -- --out evidence-package-output
npm run dispute-package -- --case A --out dispute-package-output
npm run peoples-court:prepare -- --case dispute-package-output| You are… | Your path | Time |
|---|---|---|
| A reviewer examining a converted fixture (or its ZIP attachment) — People's Court / Epistemic Labs, auditor, third party | REVIEW-GUIDE.md — pin integrity → engine gate → tamper probe → conformity records → intake projection | <10 min |
| A platform integrating — payout gating, agent marketplace, escrow, settlement | INTEGRATION.md — the boundary, the wire API, the release law; every curl executed in CI | ~5 min |
| A party with a real case — one real paid transaction, both sides reachable and willing | real-fixture intake kit — signed disclosure scope → fail-closed gate → one-command conversion | 1 session |
Programmable money moved to Bitcoin. Core gives BTC a native programmable layer, and every swap, strategy, vault interaction and BTCFI position is executed by code — and execution is not the same as intent. A front-run, a reentrancy, a hidden hop or a mutated calldata can make the transaction "go through" while doing something completely different from what was authorized.
Existing transaction-security and simulation systems address important parts of this problem, but CoreGuard focuses on the missing end-to-end evidence workflow: predeclared intent and policy → observed execution → independently reproducible evidence → Core-native commitment anchoring.
CoreGuard is an execution-truth protocol: a deterministic pipeline that turns a declared intent + policy and an on-chain execution into a single, cryptographically committed Execution Receipt that anyone can independently re-verify — with zero RPC, zero trust in the issuer, and an on-chain anchor on Core.
DECLARED (before execution) OBSERVED (after execution)
───────────────────────────── ─────────────────────────────
INTENT ──┐ ┌── on-chain tx
POLICY ──┼── canonical hash ──┐ ├── receipt
EXPECTED ─┘ │ ├── block (state pinned)
│ └── trace / state delta
▼ │
COMMITMENT (anchor) │
│ │
└──► COMPARISON ◄───────┘
│
▼
EVIDENCE BUNDLE
│
▼
EXECUTION RECEIPT
│
┌─────────────────────────────┴──────────────┐
▼ ▼
INDEPENDENT VERIFIER EVIDENCE ANCHOR
(no RPC, no trust) on Core (commitments only)
| Level | Meaning |
|---|---|
| L0 · Commitment | Intent + policy committed (hashed) before execution |
| L1 · Chain Receipt | Execution captured from chain, receipt pinned to block hash |
| L2 · Deterministic Replay | Production-grade: step-by-step audit trail, cryptographic replay hash, diff, report; MATCH/MISMATCH/UNKNOWN — no partial success ever upgrades to MATCH |
| L3 · Merkle proof | Compact, privacy-friendly proof of a receipt sub-tree |
| L4 · Zero-knowledge | Fully private execution proofs (research phase) |
- VERIFIED ≠ SAFE. CoreGuard answers "did execution conform to authorization?" — never "is this strategy profitable / safe?" Risk is reported as discrete findings, never a fuzzy score.
- Anchor ≠ execution proof. The registry proves that a specific commitment was anchored on Core. The execution claim is supported by the independently verifiable evidence/replay bound to that commitment.
v0.1ships deterministic, evaluation-free rules: VALUE_LIMIT · TARGET_ALLOWLIST · RECIPIENT_ALLOWLIST · SELECTOR_ALLOWLIST · DEADLINE · SLIPPAGE_BPS (+ ORACLE_BOUND guardrail).- On-chain
v0.1is a single contract storing commitments only — evidence lives off-chain, in the receipt. No surveillance, no oracles, no protocol custody.
The on-chain Core Testnet2 (1114) hardening campaign is PREPARED / FUNDING-BLOCKED — the operator wallet holds 0 tCORE2 (see
docs/COMMUNITY.md), so no live broadcast has been made.
The staged campaign (deploy EvidenceRegistry → commitIntent → anchorProof →
three-proof on-chain verification) is ready to run the moment funding arrives.
The engine itself is proven on the deterministic 73/73 adversarial corpus and the frozen live Core Mainnet anchor below.
The anchor flow (deploy → commitIntent → anchorProof → verifyCommitment) is live on Core Mainnet (chainId 1116):
Registry: 0x037dF08F2d43c5D03759279Fe35664f6AFf9EA6E
Receipt ID: 0xeaa87ec1…44eb6 (deterministically recomputable)
Commitment: 0xc0dbfb45…1052
Proof ID: 0xecd9e6b3…a6b8
Verdict: VERIFIED ANCHOR INTEGRITY (A+B+C)
Independent cross-RPC verification (rpc.coredao.org + rpc.ankr.com) confirms the
contract bytecode, both commitIntent/anchorProof receipts, their events, and
verifyCommitment(receiptId|proofId, commitment) == true on-chain.
Full evidence bundle: scripts/verify-live.json
(frozen historical record; live re-runs write to scripts/verify-live.regenerated.json).
See docs/DEPLOYMENT.md for how to reproduce every value.
# 1. Install (no framework, zero runtime deps — Node ≥ 18 + Foundry optional)
npm install
# 2. Test + benchmark
npm test # 1405 tests — canonicalization, policy, tamper, anchor, verifier, P1/P2, provenance, pricing, encoding, attack-lab, DDE delivery/dispute suites (incl. doc-curl contract), pages-settle guard, verification-platform suite
git config core.hooksPath .githooks # install the Pages settle pre-push guard — every main push waits for the Pages build
npm run corpus # deterministic 73-scenario adversarial corpus
npm run benchmark # 73/73 pass
# Authoritative numbers live in docs/STATUS.md (one source of truth).
# 3. Runnable demos
node examples/transfer/run-demo.js # transfer: valid → mutate → tamper → INVALID
node examples/swap/run-demo.js # swap: slippage guard + substitution → INVALID
node examples/multistep/run-demo.js # batch strategy: commitment binds one execution
node examples/live/live-verify.js # verify any on-chain tx via public RPC (read-only, needs no funds)
# 4. Phase 1 — Execution Firewall + protocol SDK (plan-90d-repo §2)
npm run demo:vault # reference Vault ladder: deposit ALLOW → VERIFIED → anchor plan
npm run demo:attack # re-runs the same intent; six attacks BLOCKED + post INVALID
npm run create:integration -- my-dapp # scaffold a consumer integration (intent/policy/verifier/tests)npm run verify:levels # L0-L4 machine: commitment, chain-confirmed receipt, replay, merkle, L4 boundary
npm run integration:states # 13-state integration machine: doorway records + no-silent-pass verdict
npm run partner:sandbox # 8 partner scenarios, offline mock chain (VERIFIED / MISMATCH / UNKNOWN / REJECTED)
npm run attack-lab # 10 tamper cases — tampered → FAIL, unknown → UNKNOWN, valid → VERIFIED
npm run passport:v2 # the portable Evidence Passport (deterministic object)
npm run adapters:status # four provider surfaces, all DRY_RUN — no live claim
npm run observability # local event sink self-check
npm run webhook # CG-WH/1 receiver: HMAC + replay window + idempotency
npm run x402 # X402/1 harness: no price opens a payment gate without an owner-locked quote
npm run conformance:report # writes docs/conformance-report.json (CG-CR/1, badgeIssuers 0)
npm run quickstart # the three-verb integration path: commit / capture / verifyMap and rules: docs/verification-and-integration-platform-2026-09-26.md. Commercial tiers (prices LOCKED, revenue $0): docs/commercial-packaging-2026-09-26.md.
The four commands below are the honesty layer. They do not make the project look better; they make it harder to describe than it is. Everything here runs offline with no credentials and no network.
npm run claims # CG-CL/1: 28 claims derived from committed sources, one status each
npm run claims:audit # fails if a VERIFIED claim has no evidence, or an evidence path is missing
npm run badge:verify # CG-BDG/1: re-derive every badge digest from its record, byte for byte
npm run badge -- --issued # list every badge the owner has ever issued (docs/badge-issuances.json)
npm run partner:journey # CG-PJ/1: ten integration legs over one bundle
npm run integration:replay # CG-IR/1: replay a bundle through L0-L3, no partial credit
npm run release:gate # CG-RG/1: 18 legs, and the gate audits its own source
npm run release:gate:independence # the gate's self-audit alone — fast, no test runFour rules that the machine enforces, not the prose:
VERIFIEDrequires a chain authority;MISMATCHrequires that someone was ASKED. The verdict turns on whether anyone was asked. No authority at all →UNKNOWN/NO_CHAIN_EVIDENCE(nobody was asked). An authority that does not know thetxHash→MISMATCH/TX_NOT_FOUND(it was asked, and it contradicted you). A receipt too malformed to ask with →UNKNOWN/EVIDENCE_INCONSISTENT. Only the middle case is a contradiction; the twoUNKNOWNcases are absent evidence, never absolution, and neither isVERIFIED.- A clean partner journey is
MATCH, notVERIFIED. L2 is the weakest link, and inflating it would inflate the evidence. - A badge's artwork is its proof. Hand-edit one byte and
verifyBadge()fails.issuerCountis 0: nothing is auto-issued, and only twoNOT ISSUEDspecimens exist, and the one recorded issuance is first-party only: the CG-CS/1 self record minted to CoreGuard itself (DF6E20C032A8, listed bynpm run badge -- --issued) proving the machine end-to-end — never third-party validation, and never a badge for any counterparty. Issuance is an explicit owner decision:npm run badge -- --issue --record <file> --i-am-the-owner-and-competent-to-issuemints ISSUED artwork underdocs/badges/issued/ONLY from a committed CG-CS/1 record whose six criteria all pass, records it indocs/badge-issuances.json, and refuses a non-conformant record outright. - A gate that cannot assert anything fails. A leg that proves nothing is
FAIL, never a quiet pass — a green check with no assertion behind it is worse than no check, because it gets trusted.
What is not claimed anywhere: third-party badge issuance, a named integrator, an unlocked price, external review, a live-chain authority, or any revenue. See docs/badge-system-2026-09-26.md and §9 of docs/owner-decisions-and-claimable-facts-2026-09.md.
npx coreguard demo allow # DEPOSIT 1 BTC → Vault A, recipient = mine, slippage ≤ 50bps
npx coreguard demo attack # same intent, six attacks BLOCKED (target · recipient · amount
# · callback · expired · calldata) + mutated execution → INVALIDThe @coreguard/sdk guard surface drives this whole ladder in three calls:
import { createGuard } from "@coreguard/sdk";
const guard = createGuard();
const pre = await guard.authorize(intent, { declaration, policy, activePolicyIds, simulation, authorityAtState, evm });
const v = await guard.verify({ chain, intent, policy, trace }); // VERIFIED | INVALID | …
const plan = await guard.anchor(v.receipt); // CGEP/1:PROOF commitment + proofIdauthorize is PRE-only and fail-closed (never ALLOWs unmodeled context); verify
recomputes every receiptId from the payload; anchor is a pure offline commitment
plan. See docs/plan-90d-repo.md §2.
node packages/cli/src/index.js analyze --intent <...> --policy <...> --trace <...> # on-chain or offline
node packages/cli/src/index.js verify --receipt <...> [--intent <...> --policy <...> --trace <...>]
node packages/cli/src/index.js verify-run --receipt <...> [--evidence <...> --intent <...> --policy <...> --trace <...>] [--rpc <url>] [--json]
# CGEP/1:VERIFY-RUN surface; exit 0=VERIFIED 2=INVALID 3=UNVERIFIED 4=INCONCLUSIVE
# e.g. --bundle examples/transfer/verify-bundle.json
node packages/cli/src/index.js verify-provenance --manifest <...> --evidence <...> [--json]
# CGEP/1:VERIFY-PROVENANCE surface (AgentProof); same exit-code discipline
node packages/cli/src/index.js report --receipt <...> # human-readable receipt
node packages/cli/src/index.js demo allow|attack # reference Vault ladder (allow | attack)
npx create-coreguard-integration <name> # scaffold a consumer integration projectverify-run is read-only: --rpc performs chainId/transaction/receipt/block
binding only — it never sends or broadcasts. See docs/VERIFY-RUN.md.
The Delivery & Dispute Evidence layer is embeddable: any agent platform, escrow provider or settlement tooling can hold a payout until delivery evidence and an explicit party acceptance say otherwise — while never letting execution proof decide conformity. One sentence binds every report the SDK returns:
Execution verification does not decide delivery conformity.
The gate has exactly one key, and it is not a receipt:
| Act | What happens | Gate |
|---|---|---|
| pending | delivery submitted, no verdict yet | 🔒 HOLD |
| party act | client records REJECTED on a named criterion (e.g. C-QUALITY: 2 color tokens, 3 required) | 🔒 HOLD |
| tamper | provider re-submits after flipping one artifact byte → 422, E3 names the byte and both hashes |
🔒 HOLD |
| the boundary | evidence VERIFIED on the wire, client's REJECTED verdict on file — execution and payment settlement proven, neither decides conformity | 🔒 HOLD |
| counterfactual | client records ACCEPTED on the same criteria evaluations | ✓ RELEASE |
The only thing that opens the gate is a party acceptance record resting on criterion evaluations. Signatures, receipts and settlement are admissible evidence — never a verdict.
node scripts/create-integration.mjs my-escrow-dapp --dde # from this repoGenerates a working DDE/1 payment-gate scaffold under ./my-escrow-dapp/:
ten pinned evidence records (dde-fixture/ + hashes.json), a standalone
boundary engine (engine-dde.mjs, zero dependencies, CI-checked against the
in-repo engine on the shipped fixture), a one-command verifier, the release
loop with both scenarios, and 5 contract tests — runnable immediately:
cd my-escrow-dapp
node verify-dde.mjs # → VERIFIED · EXECUTION_EVIDENCE_ADMISSIBLE — CONFORMITY_UNDECIDED_BY_ENGINE
node payout-gate.mjs # → HOLD (party REJECTED) — then swap in your ACCEPTED record to release
node --test # 5/5 greenThe shipped fixture is honestly labeled (SYNTHETIC, realDisputeExists: false) and its execution record is an OWNER-DECLARED placeholder —
paymentSettled: false, a zero txHash, provably settling nothing — so nothing
in the scaffold can be mistaken for a verified execution claim.
For a case you already drove through the prelude gate
(examples/real-fixture-intake/ — secret scan, consent replay, pin
integrity), pass the gate-green candidate directory and the generator
converts it in place of the static synthetic bytes:
node scripts/create-integration.mjs my-escrow-dapp-real --dde --fixture-real <candidate-dir>
cd my-escrow-dapp-real
node verify-dde.mjsThe gate runs first through its own entry point — a RED gate scaffolds
nothing at all; the converter re-pins SHA-256 over the real records and
requires the committed boundary engine to verdict VERIFIED, or the whole
scaffold is rolled back. Origin becomes REAL without ever becoming an
adjudication: the payout gate keeps releasing only through party consent, not
through engine verification or payment settlement.
import { verifyFixture, releaseWhen } from "@coreguard/delivery/sdk";
const report = await verifyFixture({ fixtureDir: "./cases/case-17" }); // or { fixture }
const gate = releaseWhen(report, () => acceptanceOnFile() === "ACCEPTED"); // YOUR condition
if (!gate.release) holdPayout(gate.reasons); // named reasons, never vague symbols
else releasePayout();verifyFixtureruns the full fail-closed gate (F0–F3, E3–E5, B1–B3) — zero checks added, zero stripped. Every report carries the boundary banner (boundaryCode: "DDE-BOUNDARY"), so quoting a report quotes the boundary.releaseWhenstructurally refuses release without a VERIFIED report, even if your predicate says yes; a throwing predicate is a HOLD, not a crash.- Consent replay (E5) runs only with an EVM adapter you inject; absent →
NOT_RUN, never fabricated. The SDK never signs, never broadcasts, never judges conformity.
See it run in the browser — the two live reference pages replay these examples over the real fixture in your tab: the honest fixture → HOLD on the API page and HOLD on the SDK page · the counterfactual ACCEPTED → RELEASE · a flipped artifact byte → 422 on the API page and REFUSED on the SDK page.
(Inside this repo, import from packages/delivery/sdk.js — the package
specifier above is the installed surface with the same exports.)
@coreguard/sdk resolves the full guard closure (canonical, crypto, policy,
trace, evidence, replay, evm, provenance, intent, verifier, firewall) and
@coreguard/delivery adds the DDE/1 layer — 13 packages total, all held to
the same publish bar:
npm run publish:check # tarball contents, escaped imports, dependency truth,
# and INSTALL PARITY: every package is packed, installed
# from its tarball with its real deps, and its public
# specifiers are import-probed — in CI on every push
npm run release:dry # the release plan: token gate + 13-package dependency-ordered publish listActual publishing is a manual, double-gated workflow
(Actions → npm release (gated), type RELEASE, environment npm-release):
it runs scripts/release-please.mjs, which refuses without NPM_TOKEN, runs
the full publish gate, then publishes with --provenance --access public in
dependency order — fail-fast, nothing half-published. Every push CI-rechecks
the gate, so the registry-bound surface can never silently rot.
# from a repo checkout — loopback by default; a public bind is a deliberate act
node -e "import('./packages/delivery/http.js').then(m => m.startDeliveryEndpoint({ port: 8787 }))"
# from an installed package: import { startDeliveryEndpoint } from "@coreguard/delivery/http";
curl -sS -X POST http://127.0.0.1:8787/verify \
-H "content-type: application/json" --data-binary @fixture.json
# → 200 VERIFIED (decision: EXECUTION_EVIDENCE_ADMISSIBLE — CONFORMITY_UNDECIDED_BY_ENGINE)
# or 422 FIXTURE_REJECTED with the failing check namedPer-address rate limiting (429 + retry-after, /health exempt), a pre-parse
1 MiB size gate, and a decision vocabulary that never exceeds
EXECUTION_EVIDENCE_ADMISSIBLE — CONFORMITY_UNDECIDED_BY_ENGINE /
FIXTURE_REJECTED — no network path can decide conformity. Full status-code
table and wire honesty rules: docs/delivery-dispute-boundary.md §6.
node examples/agent-platform-integration/run-integration-demo.mjs # SDK arc — 4 holds, 1 release (exit contract)
node examples/agent-platform-integration/run-http-payout-gate.mjs # wire-level — 9 scenarios incl. mutual acceptance, a later dispute freezing the payout, and a procedure-closed record
npm run benchmark:dde # verify perf: median < 50ms budget (measured ~0.7ms)Both demos exit 0 only on the exact arc: HOLD ×4 → RELEASE ×1 (SDK) and the
nine-wire arc — escrow stays HELD through acceptance disputes, an unproven
closure claim (422), and only RELEASES once closedAtUtc establishes the
record is closed — any drift from the boundary fails them, and CI runs both on
every push. Fixture and
records: examples/delivery-fixture/ · live
bilingual demo: DELIVERY-DISPUTE-DEMO.html ·
HTTP endpoint reference with an in-page live engine: DDE-API-REFERENCE.html
(all six wire codes captured from the real DDE/1 handler running in the browser tab) ·
SDK reference with verifyFixture + releaseWhen running live in-page: DDE-SDK-REFERENCE.html
(the honest gate arc — HOLD, RELEASE, structural REFUSED — captured from the real SDK over the real fixture) ·
one-page shareable integration summary (drop-in for discussions and social posts):
INTEGRATION.md
— its every runnable fence executes in CI against the real endpoint.
Got a real paid transaction with two consenting parties? The
real-fixture intake kit converts it into a
redacted review-ready fixture: bilateral consent with a named disclosure
scope, a removal checklist, a fail-closed pre-publication gate, and
convert-to-fixture.mjs — one command from a gate-green candidate to the
ten records with re-pinned hashes and an engine-verified verdict
(exit 0 ready · 1 gate red/rejected · 2 usage) — with a --out-zip mode
producing a byte-deterministic, audit-manifested archive ready to attach
to a GitHub discussion comment. The whole path is CI-exercised on every
push (candidate build → gate → both conversion modes → unzip → engine on
the extraction → red-path refusal), so the route a real case will travel
is watched continuously, not trusted from unit tests alone. Reviewers
get a one-page path through any converted fixture:
REVIEW-GUIDE.md — pin integrity, engine gate, tamper
probe, conformity records, and the intake projection in under 10 minutes.
Who is actually behind this execution? AgentProof extends the receipt with a two-part answer that is declared, never inferred:
- executorType (CGEP/1 §4 taxonomy):
HUMAN·AI_AGENT·BOT·AUTOMATION·ORGANIZATION·MULTISIG·CUSTODIAN·SMART_CONTRACT·PROTOCOL·UNKNOWN - cryptographic authority: an EIP-712-signed REGISTRATION (identity root)
- per-execution STAMP manifest, replay-verified against the actual
tx.from(direct or via signed delegation chain), anchored to the EvidenceRegistry.
- per-execution STAMP manifest, replay-verified against the actual
A human is never shown as proven from behavior — human-ness renders
DECLARED or ATTESTED at most (personality is never guessed). Badge states
come from the open verifier only, so every badge is reproducible by npm run verify-provenance. Phase A = EOA signer binding; smart-contract/multisig
authorization needs EIP-1271 (Phase B). Spec: spec/CGEP-1-AGENT-PROVENANCE.md.
npm run verify-provenance -- --manifest examples/provenance/manifest.json --evidence examples/provenance/evidence.json
# exit code: 0=verified · 1=cli/input error · 2=invalid · 3=not proven/unverified · 4=inconclusiveAutonomous actors now move value: AI agents, keeper bots, trading robots, treasury daemons and company-controlled multisigs. The fastest-growing question in that world has no verifiable answer today — not "is this transaction risky?", but "who declared responsibility for this exact execution, under what authority, and can anyone prove it afterward?" CoreGuard is the execution- provenance + cryptographic-authority layer for that question, and AgentProof answers who as a declared, signer-bound fact (never a behavioral guess).
The honest positioning line, safe to repeat: CoreGuard verifies declared execution provenance and cryptographic authority for a specific execution. It is not an agent-identity registry, not a trust-score system, not an "AI detector". See
spec/agent-provenance-prior-art.md(Gate G-1).
2026 made agent trust a crowded field — but from other layers: x401 (Proof, 2026-06-25) authorizes actions at request time (who authorized + scope); World ID + Coinbase AgentKit (2026-03) anchors agents to biometric-verified humans with x402 payments; Self Protocol (2026-04) binds human↔agent in zk on ERC-8004; Arkose Agent Trust Manager (2026-06-16) classifies agent traffic behaviorally. Post-execution on-chain provenance — "did the transaction match the declared authority, re-derivable by anyone" — is the layer none of them ship. That is the CoreGuard layer. The dated matrix and the overtake roadmap live in docs/competitive-intelligence-overtake-2026-09-20.md.
CoreGuard is built for Core's stack — the native programmable layer for Bitcoin — and is already proven live there (chainId 1116; anchor verdict VERIFIED ANCHOR INTEGRITY; independent cross-RPC readback). The product surface DApp carries Core's visual identity (gold) alongside CoreGuard's own (deep green): consistent with the ecosystem, never a rebrand — every party keeps its own color and fingerprint.
Aligned Core programs are tracked as public, dated, planning-only facts (never eligibility claims): Core Connect Global Buildathon (AI + Web3 infra categories), Core Commit Program (business-model / PMF criteria), and Core Ignition Builders' Incentive. Details + the criteria pre-mapping live in docs/adoption/, and the honest "how CoreGuard drives CORE usage/scarcity + where it sits in Core's 2026 roadmap" mapping is in docs/adoption/coreguard-core-value.md.
The product shows a three-tier structure — Starter (free, 10/week) →
Pro → Enterprise / Core team — and the on-chain commission side is real:
EvidenceRegistryV3 charges a flat, explicit feeWei paid atomically with
the anchor (any mismatch reverts), routed to an operator-only treasury, with
feeWei = 0 degenerating to the free path.
No committed pricing. Per standing governance, pricing stays locked until
the Decision Gate opens (after Counterparty #1). The machine view stamps
gated: true on every output and never bills. See docs/pricing.md.
| Network | Chain ID | RPC |
|---|---|---|
| Core Testnet2 | 1114 | https://rpc.test2.btcs.network |
| Core Mainnet | 1116 | https://rpc.coredao.org |
forge build # 0.1 evidence registry (clean)
powershell -File scripts/anchor-local.ps1 # or: bash scripts/anchor-local.sh
# local anvil fork anchor → scripts/anchor-proof.json
npm run anchor:plan # → scripts/live-anchor-planned.json (offline proofId plan)
npm run anchor:verify # → scripts/verify-live.regenerated.json (frozen bundle stays)spec/ CGEP/1 (draft) · master spec · canonical encoding · receipt · levels ·
threat model · privacy model · competitive kill matrix · killer memos
packages/ canonical · intent · policy · trace · evidence · firewall · verifier · evm · sdk · cli · delivery · provenance · pricing (ESM)
— sdk/guard.js = guard.authorize/verify/anchor Phase-1 surface
— provenance = Actor Identity Card + AgentProof surfaces (declared, never detected)
— pricing = hypothesis plan table, Decision-Gate-locked (no enforcement, never bills)
— delivery = DDE/1 execution/acceptance boundary (engine + SDK + HTTP endpoint, zero-dep)
— peoples-court-adapter = ADAL/1 → uploaded-surface dry-run mapper (offline, credential-free)
contracts/ EvidenceRegistry.sol — commitment registry (deployable, `--legacy`)
benchmarks/ generator + 73-scenario corpus: valid/invalid/mutations/tamper/performance
test/ canonicalization · policy · tamper suites + adversarial runner + P1 suites
· firewall/ (engine + ws1) · firewall/attack-lab · sdk (verifyBinding + guard)
examples/ transfer · swap · multistep · live · vault (Phase-1 reference ladder) (runnable, with READMEs + artifacts)
delivery-fixture/ — DDE/1 bilateral dispute fixture (synthetic, replayable: node examples/delivery-fixture/verify-fixture.mjs)
agent-platform-integration/ — payout gated on DDE: SDK arc + wire-level gate with a criteria-based scenario rejection (runnable)
real-fixture-intake/ — real-case intake: consent + signed disclosure scope → removal gate → convert-to-fixture.mjs → review-ready REAL fixture
reference-tribunal/ — local synthetic adjudicator + mock escrow (fail-closed settlement semantics; NOT People's Court)
— external integration path (three tiers): delivery-fixture = schema proof · agent-platform-integration = embed the gate · real-fixture-intake = go real
templates/ integration/ — consumer scaffold for create-coreguard-integration
scripts/ anchor-local.ps1/.sh — local fork anchor proof ·
compute-commitment — offline commitment plan ·
verify-anchor — three-proofs anchor checker
docs/ deployment · funding · contributing · security · delivery-dispute-boundary.md (DDE/1) · pricing.md
evidence-package-standard.md (EVP/1) · dispute-package-standard.md (ADAL/1)
article-missing-verification-layer-agentic-disputes.md + publish-ready X/LinkedIn drafts
integration-surface-map-2026-09.md (Phase C) · funding-roadmap-2026.md (Phase D)
revenue-path-2026-09.md (Phase E) · ip-workstream-2026-09.md (Phase F)
DELIVERY-DISPUTE-DEMO.html — live bilingual DDE demo
DDE-API-REFERENCE.html — live HTTP endpoint reference (engine runs in-page)
INTEGRATION.md (repo root) — one-page shareable integration summary (CI-executed fences)
coreguard-dapp-core.html — Core-branded DApp surface (identity · plans · treasury · on-Core)
docs/adoption/ WS-5 — adoption & institutional proof (demand/evidence layer)
submission/ Investor / Core Submission Pack (15 items) — run `npm run demo:90s`
| Milestone | Status |
|---|---|
| v0.1 — Evidence protocol (intent → trace → evidence → receipt → verifier → anchor) | 🔬 Testnet2 campaign PREPARED / FUNDING-BLOCKED (engine 73/73 PASS, live Mainnet anchor below) |
| v0.1 — On-chain anchor on Core | ✅ live on Mainnet 0x037dF08F2d43c5D03759279Fe35664f6AFf9EA6E (VERIFIED ANCHOR INTEGRITY) |
| v0.2 — Execution Firewall (simulation-gated smart accounts, intent-based authorization) | ✅ Phase 1 delivered: engine (packages/firewall, attack-lab) + @coreguard/sdk guard.* + reference Vault ladder (`npx coreguard demo allow |
| v0.3 — Passport / reputation + risk findings | ✅ first-pass shipped (2026-09-25): integration state machine + unified states · CoreGuard Conformance Suite (CG-CS/1) · Evidence Passport machine-readable registry · Reputation (CG-RP/1) + risk-findings (CG-RF/1) as enforced deterministic code (npm run ladder:status / ladder:passport / ladder:dashboard / ladder:findings / ladder:reputation — scratch docs/live-integration-and-adoption-ladder-2026-09-25.md); reputation = recorded external milestones only (never an amount); findings are risk findings only, never a fuzzy safety score |
| v0.3.1 — Verification & Integration Platform | ✅ shipped (2026-09-26, continuous build): L0–L4 machine (verify:levels — L1 now needs a chain confirmation, structure alone is UNKNOWN) · 13-state integration machine (integration:states) · six-method adapter contract with DRY_RUN honesty (adapters:status) · Partner Sandbox 8 offline scenarios (partner:sandbox) · Attack Lab 10 tamper cases (attack-lab) · Evidence Passport v2 (passport:v2) · dashboard Control Plane (derived only, $0/0/0 stay visible); map: docs/verification-and-integration-platform-2026-09-26.md |
| v0.3.2 — Commercial surfaces | ✅ shipped (2026-09-26): the two roadmap rows that were prose-only are now real code — CG-WH/1 webhook receiver (npm run webhook: domain-separated HMAC over exact bytes, replay window that rejects stale AND future-dated deliveries, mandatory Idempotency-Key whose replay never re-runs the handler; no keyless mode, DRY_RUN never performs) · X402/1 harness (npm run x402: canonical 402 challenge, and no price — none, zero, or unlocked — opens a payment gate; settle() books $0) · CG-CR/1 machine-readable conformance report with badgeIssuers: 0 (conformance:report) · three-verb quickstart (quickstart) · five-tier commercial packaging with prices LOCKED and a build-failing test that checks every cited path and any $ amount (docs/commercial-packaging-2026-09-26.md) |
| v0.4 — ZK privacy proofs (L4) | 🔬 research |
CoreGuard is looking for funding and builders — milestone-based, Core-native, auditor-honest. Details: docs/FUNDING.md.
Evaluating us? Start with the Core Submission Pack (15 items) —
npm install && npm run demo:90s reproduces the Mainnet-verified demo in seconds.
MIT — see LICENSE. Protocol spec CGEP/1 is a draft for open discussion, not a claim of standard.