A paid, callable AI agent on the CROO Agent Protocol (CAP) that performs deterministic, third-party-verifiable number-theory computation: integer factorization, primality proof, and factorization auditing — each delivered with a content hash that anyone can independently reproduce.
Hackathon track: Data & Verification Agents — provenance, output checks.
Most agents on a marketplace are LLM wrappers whose output you must trust. This one is different: every result is reproducible. Re-run the same request anywhere and you get a byte-identical result and the same SHA-256 attestation. No trust required — verify it yourself.
The agent exposes one service with three operations. The input is a JSON object
sent as the order's requirements; the output is a structured JSON
(SCHEMA) deliverable.
op |
Input | Returns |
|---|---|---|
verify_prime |
{"n": "<int>"} |
Miller-Rabin verdict (exact below 3.317×10²⁴) |
factor |
{"n": "<int>"} |
Full prime factorization + product/primality checks |
verify_factorization |
{"n": "<int>", "factors": ["<int>"]} |
Audits a claimed factorization — catches wrong products and composite "factors" |
Every response carries:
content_hash—sha256:over the canonical (sorted-key, whitespace-free) payloadexecution_log— what ran, and timingverified/is_prime— the verdict
The hash is computed over the payload only (verdict + method + inputs),
never over the timing log. So any third party can take the delivered schema,
remove content_hash and execution_log, recompute the SHA-256 over what
remains, and confirm it matches. Determinism makes the attestation meaningful.
The reproducibility claim above isn't theoretical. During the hackathon, two
independent third-party buyers — different wallets, no coordination between
them — each ordered a primality proof of 1000000007:
| Order | content_hash |
|---|---|
a08d9b9a… |
sha256:8536bccb…944b |
04f61438… |
sha256:8536bccb…944b |
Same input → byte-identical hash, each paid and settled on-chain on Base. That is the entire thesis demonstrated live: change one digit of the input and the hash changes completely; reproduce the exact input and you get the exact hash, on any machine. Verification you don't have to trust.
Full hash for both orders:
sha256:8536bccb9e6d4826f88c77fbf754f373ff5e523635730b5b750d9d3991ef944b
Why this needs a verifiable marketplace, not a plain API. On a normal API you get an answer and a bill, and you trust the vendor. Here, settlement happens on-chain via CAP and the deliverable is bound to a reproducible attestation, so the buyer — human or agent — audits the result independently and payment is conditioned on delivery. The value isn't the arithmetic; it's the trust-minimized settlement wrapped around it.
Live A2A traction
- 5+ distinct third-party buyer wallets, 100% completion rate, < 1 min average delivery.
- Operated both sides of CAP: sold verification, and bought from other agents (ZERU — DeFi research; VeriClaim — insurance-claim audit) for genuine agent-to-agent composability.
- Robust input handling: a real buyer pasted a loose
{"text": …}envelope containing prose plus two separate commands, and the normalization layer still resolved it to the correct verdict and a reproducible hash.
Two files, cleanly separated so the compute logic never touches the network:
verifier_core.py Pure, deterministic, dependency-free verification engine.
No network, no SDK. request dict -> hashed result dict.
>>> This is where heavier engines plug in (see below). <<<
provider_verifier.py Thin CAP adapter. Translates the on-chain order lifecycle
into calls to verifier_core. The only file touching web3.
test_local.py Offline simulation of the full negotiate->pay->deliver
loop. Validates logic, determinism, and verifiability
with zero on-chain cost.
AgentClient(Config(base_url, ws_url, rpc_url), sdk_key)— client initclient.connect_websocket()→EventStream— live order eventsstream.on(EventType.NEGOTIATION_CREATED, …)— incoming workclient.get_negotiation(negotiation_id)— read the requester's inputclient.accept_negotiation(negotiation_id)— accept; returns theOrderstream.on(EventType.ORDER_PAID, …)— escrow funded → run the computationclient.deliver_order(order_id, DeliverOrderRequest(SCHEMA, …))— deliver proofstream.on(EventType.ORDER_COMPLETED, …)— settlement + on-chain reputation
All gas is sponsored by CROO; settlement is USDC on Base.
At agent.croo.network: My Agents → Register Agent. This mints an AA wallet + Agent DID and shows your API Key once — store it.
Add a service: Name Computational Verification, a price per call in USDC, an
SLA, Deliverable = Schema, Requirements = Schema.
pip install croo-sdk
export CROO_API_URL="https://api.croo.network"
export CROO_WS_URL="wss://api.croo.network/ws"
export CROO_SDK_KEY="croo_sk_..." # provider key from step 1
python provider_verifier.py # status flips to OnlineRegister a second agent, deposit USDC to its AA wallet, then send a request
with requirements, e.g. {"op":"factor","n":"600851475143"}.
python verifier_core.py # engine self-test
python test_local.py # full loop + determinism + verifiability checkstest_local.py mirrors the exact provider code path and asserts 18 checks,
including negative cases (a wrong product and a composite "factor" are both
correctly rejected).
verifier_core.factorize() ships with a pure-stdlib Pollard rho-Brent engine so
the agent runs anywhere. It is marked >>> SWAP POINT <<<. Replace its body
with a GPU/ECM factoring backend or a factordb cross-check for large inputs.
The contract is simple and is what keeps the rest of the system unchanged:
return a list whose product equals
nand whose every element passesis_probable_prime.
Nothing in the CAP layer changes when you upgrade the engine.
The CPU engine above is canonical by design: stdlib Miller-Rabin (deterministic below 3.317×10²⁴) and Pollard rho-Brent, pure-Python, no special hardware. That is deliberate — the whole pitch is anyone can reproduce the SHA-256 attestation, and a CPU-canonical path keeps reproduction universal (no GPU required to verify).
For the scale regime — primality at thousands of bits, or massive batches — there
is a real, authorial GPU backend available to plug in behind the same PRIME_ENGINE
contract:
mr_blackwell — a native Miller-Rabin
CUDA kernel for NVIDIA Blackwell (sm_120). It is a CGBN replacement built from
Montgomery CIOS modular multiplication and hand-written PTX carry chains, not a library
wrapper. Throughput on an RTX 5070 reaches ~1.8M PRP/s.
Where it helps — and where it doesn't (measured, not claimed):
| Workload | Best engine | Why |
|---|---|---|
One small n per order (the agent's typical load, n < 3.3×10²⁴) |
CPU | A single ~84-bit test finishes in microseconds; a GPU launch+sync costs ~ms. GPU would be pure overhead here. |
Single very large n (thousands of bits) |
GPU | Big-integer modmul throughput on Blackwell wins once the work per number dwarfs launch latency. |
| Large batches of candidates | GPU | This is where the kernel was built to shine — prime-gap / sieve pipelines, not order-at-a-time agents. |
So the GPU backend is offered as an optional accelerator for the scale regime, never
as the canonical path. Wiring it into the per-order hot path would add latency without
correctness gain and would break universal reproducibility — so the default stays CPU.
The capability is real and self-contained; the design choice to keep CPU canonical is
deliberate. (Companion factoring backend for very large composites:
ecm_blackwell, GPU ECM up to 308 digits.)
Requester Provider (this agent)
│ │
├─ NegotiateOrder (requirements JSON) ─────►│ get_negotiation -> accept
│◄── order_created ────────────────────────┤
├─ PayOrder (USDC escrow in CAPVault) │
│ │◄── order_paid
│ ├─ compute_result() + deliver SCHEMA
│◄── order_completed ──────────────────────┤
├─ GetDelivery → {verified, content_hash} ├─ settled + reputation (PTS) ✓
▼ re-verify the hash independently ▼
MIT — see LICENSE.