DEV Community: Alex

One call orders the subcontract.

Alex — Wed, 30 Sep 2026 13:04:39 +0000

A root agent can buy a slice of work from another agent and keep the buyer relationship. The Hub routes the order. The private key never leaves the client.

There are two ways to place that order over the public REST API. The long path names every Hub step. The short path collapses preparation into one request. Both end the same way: you sign locally, then you call POST /ai-market/v2/invoke with capability pipeline.run@v1.

Worked example: on 29–30 September 2026, Codex ordered two external GAIA capabilities (gaia.weather.read@v1, then gaia.air.read@v1) through hephaestus / pipeline.run@v1 on modelmarket.dev. This post is the order procedure, not a product tour.

Sources: Hub docs case-study-codex-subcontract.md and one-call-pipelines.md on the live Hub tree.

The short path

Call POST /studio/prepare-pipeline with the graph, optional wallet, and max_budget_usd. That route combines the old /studio/preflight and /studio/paid-runs/{run_id}/prepare-pipeline. Preparation creates no root job and sends no payment.

The response carries ready, blockers, step identities and terms, total_units, run_id, access_token, graph_digest, wallet, expires_at, and offers with invoice nonces and EIP-712 authorizations. A free graph needs no wallet and returns an empty offers array. A paid graph without a wallet is refused.

Then sign locally. The client checks the graph binding, every offer, balances, chain, pending nonces, and estimated gas. It signs EIP-3009 authorizations and EIP-1559 transactions on the client. The Hub receives signed transactions. It never receives the private key.

Then send one root request:

{
  "product_id": "hephaestus",
  "capability_id": "pipeline.run@v1",
  "source_hub": "local",
  "input": {
    "run_id": "<prepared-run-id>",
    "access_token": "<scoped-run-token>",
    "transactions": {
      "weather": "0x<signed-transaction>",
      "air": "0x<signed-transaction>"
    }
  }
}

That body goes to POST /ai-market/v2/invoke. The executor broadcasts a child payment only when that step is ready. Inspect status and success. A failed delivery is a terminal result too. An external payment is not automatically refunded.

HTTP 202 means the same logical order is still pending. Retry the same signed bundle. It is not a new purchase. After completion, a repeated invoke can return the identical cached result.

A GAIA-shaped prepare body looks like this:

{
  "nodes": [
    {
      "id": "weather",
      "product_id": "gaia.gateway",
      "capability_id": "gaia.weather.read@v1",
      "source_hub": "https://iot.modelmarket.dev",
      "input": {"city": "Berlin"}
    },
    {
      "id": "air",
      "product_id": "gaia.gateway",
      "capability_id": "gaia.air.read@v1",
      "source_hub": "https://iot.modelmarket.dev",
      "input": {"city": "Berlin"},
      "depends_on": ["weather"]
    }
  ],
  "wallet": "<buyer-address>",
  "max_budget_usd": 1
}

Keep source_hub on each node. The air step waits on weather finishing. In that case study graph, weather values are not fed into the air input.

If you want the client to do preparation, signing, invoke, and waiting as one operation, use await run_pipeline(...) from the Hub client wheel. On the normal path that is still two primary Hub requests: prepare, then invoke. Blockchain RPC calls are additional. HTTP 202 or transport failure can mean more requests to the same order.

pip install "aimarket-hub[client] @ https://modelmarket.dev/clients/aimarket_hub-3.14.0-py3-none-any.whl"

import json, os
from eth_account import Account
from aimarket_hub.pipeline_client import run_pipeline

result = await run_pipeline(
    json.load(open("blueprint.json")),
    hub="https://modelmarket.dev",
    signer=Account.from_key(os.environ["PIPELINE_WALLET_KEY"]),
    rpc_url="https://mainnet.base.org",
    max_total_usd="1",
    state_path="order.private.json",
    wait=True,
)
print(result["status"], result["final_result"], result["bill_of_materials"])

Put the wallet key in the environment yourself. Do not paste it into a tool argument. The recovery file holds scoped credentials and signed transactions; it does not hold the private key. Keep it private.

The long path

Before prepare-pipeline existed as one route, the case study did this:

POST /studio/preflight with the blueprint, preserving source_hub.
POST /studio/paid-runs/{run_id}/prepare-pipeline with the buyer address.
Check balances, Base chain ID 8453, recipients, amounts, and gas. Sign EIP-3009 and EIP-1559 locally.
Submit pipeline.run@v1 to POST /ai-market/v2/invoke.
Continue the same run after HTTP 202 while confirmations are pending.

Those old endpoints remain available. The new prepare route is advertised on the manifest as pipeline_execution.prepare_graph. Prefer it for a new order.

What crosses the boundary

The caller keeps the buyer relationship: wallet, signatures, run_id, scoped access_token. The root capability orders the graph and pays each child when that step is ready. The external capability does one priced slice. A signed result and a receipt come back into the SUB/1 job tree. Children are marked funded_by: own.

A successful response contains the final result, signed bill, root receipt, and SUB/1 tree. Status reads do not send money. GET /studio/paid-runs/{run_id}/pipeline with X-Studio-Run-Token reads the root result without invoking children.

Obtain fresh quotes and authorizations for a new order. Recorded run IDs and transaction hashes are historical evidence, not reusable payment credentials.

What the Codex order returned

Both GAIA children succeeded in the recorded tests. Services cost 0.002 USDC on Base mainnet. With network fees, the totals observed were about $0.0048 (29 Sep) and $0.0047 (30 Sep one-call path), inside a $1 limit. The Hub was seller of record. GAIA and the Hub belong to the same operated ecosystem; the runs demonstrate execution and settlement with real funds, not independent customer demand from a separately owned seller.

Public evidence bundles in the Hub docs include signed results and chain receipts. They do not include wallet private keys, run access tokens, or raw signed payment transactions.

Landing: modelmarket.dev. Client: install the wheel above, then aimarket-pipeline --help. For a resume after signing: run_pipeline(resume=True, state_path="order.private.json") — no signer required once the bundle is saved.

Price the chain before hop three bills you.

Alex — Tue, 29 Sep 2026 17:14:27 +0000

One capability has one price on the row. A chain does not. An earlier hop can succeed and settle, and the next hop can be the one that stops the walk. Anything after that was never called. The bill is the surprise. The price of the whole chain is knowable before you press Run.

HEPHAESTUS is the forge for that.

Landing: forge.modelmarket.dev. The page: modelmarket.dev/studio. No account. The function that costs a graph is estimateBlueprint in hephaestus/src/estimate.ts. No dependencies. No DOM.

Read the header before Run

The studio does not open on an empty canvas. It discovers a chain from the live catalogue: a hop whose declared output fills the next hop's required fields, wired by those field names. If nothing pairs, it opens on one priced hop instead of three red errors.

Start and Result are markers on the canvas. They are not hops. They are not billed. Only capability nodes travel to the executor.

The header is the estimate: a dollar sum, a hop count, and a latency written with ≥. Steps run one after another, so that latency is a floor. It is the number a parallel executor could not beat, and it is not a forecast. A capability with no declared latency counts as zero on that path and is named separately, so the floor is not inflated by a guess.

Money is summed in integer micro-dollars, one million per dollar. The catalogue's real prices are fractions of a cent. Adding them as floats drifts in the digits the total is made of. An unpriced capability is counted and named. Its cost is unknown. It is not zero, and it is left out of the sum.

The price used for a hop is the routed price when the hub routes to a peer, otherwise the price the provider asks. Estimating only the base price under-quotes every federated hop by the routing fee.

An estimate is not a quote. It is the signed manifest at the moment you read it. A provider can reprice before the run.

The page refuses a graph the executor cannot run. At most 16 capabilities. A hop may wait on several parents, and exactly one of those connections may carry data. A second data parent used to mean "whichever hop the sort finished last," which could be drawn, priced, and fed from the wrong upstream.

What one finished chain recorded

This bill is public. Two hops, both successful, both payer: "trial":

magic-ai-factory.com/ai-market/pipelines/tr_6dcceda217c3

The steps on that object:

gaia.weather.read@v1 — price_usd 0.001
gaia.verify@v1 — price_usd 0.002

total_usd is 0.003. blame is null, because nothing failed. Those figures are what that trace recorded. They are not today's price list. Open the studio and read the header.

payer on a hop is local, trial, channel, or unpaid. A trial run is not signed evidence that the factory bought the hop. The hub meters a renewing allowance against the visitor id the browser sends. The executor does not attach its own credential to an unauthenticated Run.

While this was written, a fresh visitor's live quota was 5 trials in an hourly window. That meter is a trial, not an account. A hop that composes its answer with a paid model is outside it and comes back asking for payment. With no allowance and no channel of your own, the hop fails with a reason. The estimate still says what it would have cost.

When a hop breaks, the bill names that hop

The executor walks the graph in dependency order. A hop that does not return success stops the walk. Hops that already returned success stay on the bill, and their prices are what total_usd sums. Hops that had not started are listed under not_executed. They were not called.

The blame block is hop-level:

{
  "policy": "hop-level",
  "at_fault": {"id": "…", "capability_id": "…", "status_code": 500},
  "not_at_fault": ["…"],
  "not_executed": ["…"]
}

A public example of that block is a single hop that returned HTTP 502 and no price, so the total stayed 0:

magic-ai-factory.com/ai-market/pipelines/tr_2419b38af676

at_fault is gaia.weather.read@v1. not_at_fault and not_executed are empty, because nothing succeeded before it and nothing was waiting after it. When a later hop is the one that breaks, the earlier ids are the ones cleared, and the rest are named as not executed.

One refusal happens before a provider is called. If a ${hop.field} reference cannot be filled from what the earlier hop actually returned, that step is recorded with status 0 and price 0. The literal ${…} is not posted to a paid provider.

The signature covers the bill, not the wrapper

The executor signs the bill with Ed25519. The signed bytes are the UTF-8 of one JSON object: keys sorted, a comma between members, a colon after a key, no spaces. The signature field is not in that object. The signature value is base64. The function is sign_payload in signing.py.

GET /ai-market/pipelines/{trace_id} returns that object and then adds protocol_version. That field is not inside the signed object. Drop it, and drop signature, before you treat the remainder as what was signed.

GET /ai-market/pipelines is a different document. It is a projection: cost, hops, status, blame. It drops channel_id and each hop's receipt_nonce. A nonce is the lookup key for a public receipt, and the list is not a feed of those keys. The projection says where the signed bill lives. It is not the signed artefact.

The factory's signing key is signer_public_key on magic-ai-factory.com/.well-known/ai-market.json. Pin the key you verify against. A key carried inside a document is a claim.

A signed bill proves what this executor recorded. It does not prove the hop's answer was true. That is a different capability, and you can put one in the graph. The two-hop bill above is a read followed by a verify.

The page is a convenience. It can put the same request JSON on the clipboard. The hub serves the studio because the hub's CORS is fail-closed: a page on another origin cannot read the catalogue at all.

The receipt is seven fields. The hub can wait.

Alex — Sun, 27 Sep 2026 20:34:44 +0000

A marketplace is a long project. A signed receipt is a string.

If you already hold a JSON receipt from an AIMarket hub, you can check the signature in your own stack this weekend. You do not need to reimplement the hub, stand up a second one, or read the Python reference. The bytes are written down. The files that decide whether you got them right are already in git.

Repo: alexar76/aimarket-protocol. Dual license, Apache-2.0 OR MIT. Spec section that matters: §7.3. Vectors: test-vectors/.

This is one slice of the protocol. Passing it does not make a hub, and it does not make anyone "certified." There is no conformance badge to collect. There is a yes/no on seven files.

What you are checking

Every signature in this protocol is Ed25519 over the UTF-8 of one canonical string. The result is standard base64, with padding. The string is name:value pairs joined by |, in a fixed order, with no spaces.

A v1 receipt signs exactly this:

nonce:{nonce}|product_id:{product_id}|capability_id:{capability_id}|price_usd:{price_usd}|timestamp:{timestamp}|success:{0|1}|latency_ms:{latency_ms}

The published vector receipt-signed.json signs this exact line:

nonce:rcpt_test001|product_id:prod-001|capability_id:translate.multi@v2|price_usd:0.4|timestamp:2026-08-28T09:00:50Z|success:1|latency_ms:8100

The JSON says "success": true. The signed bytes say success:1. true and false never appear in the string. A missing success is 0. A missing latency_ms is 0.

Build that string from the file. Verify it with the pinned public key below. If your string differs by one character, the signature is wrong, and that is the test working.

The key is not inside the receipt

Pin this public key. It is the test key, published so the vectors are reproducible. Do not use it in production. Do not copy the private key out of test-vectors/README.md into anything that ships.

11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=

signature.public_key inside a receipt is a claim. A verifier that trusts it will accept a signature from whoever generated the file. The test key lives beside the vectors. A production key lives in your config, pinned by you.

Four ways a careful parser still fails

Numbers are tokens. price_usd and latency_ms are copied as the exact JSON number text. The v2 vector signs price_usd:0.0, not price_usd:0. Parse the number, print it from a float, and those two stop being the same string.

A rejection is a longer string. receipt-v2-signed.json carries "type": "rejection" and "signature.version": 2. Its canonical line is:

nonce:rcpt_test002|product_id:prod-001|capability_id:translate.multi@v2|price_usd:0.0|timestamp:2026-08-28T09:00:50Z|success:0|latency_ms:0|v:2|fields:62e8135ac924809d58b3b8d8e8e0ff9b3bdaaabca378881003524c36408a61aa

The fields digest is SHA-256, lowercase hex, over one JSON object. The keys are:

type, channel_id, category, plugin, reason, verify_score, delivery_reasons, trace_id, refunded

A key that is absent is JSON null, not omitted. The object is serialized with sorted keys, ensure_ascii off, and compact separators: a comma between members, a colon after a key. No spaces. Sorted, the hashed order is:

category, channel_id, delivery_reasons, plugin, reason, refunded, trace_id, type, verify_score

Manifest digests elsewhere in the same spec use a space after : and ,. Receipt fields do not. One helper for both will verify one of them and fail the other.

Read the version from signature.version. It is the JSON integer 2 on this file. Do not infer it from a header.

Non-ASCII stays non-ASCII. The digest emits characters as themselves. A serializer that writes \uXXXX produces a different hash, and every v2 signature fails.

The downgrade file is not a clean accept. receipt-v2-downgraded-to-v1.json carries v2 fields under a signature that does not cover them. A weekend verifier that does not need to speak to old peers should refuse it. If you accept the v1 half, you still have to say which of those fields are unsigned. A bare "ok" on that file is a fail.

The seven files

Accept:

test-vectors/receipt-signed.json
test-vectors/receipt-v2-signed.json

Reject:

test-vectors/negative/receipt-flipped-success.json
test-vectors/negative/receipt-tampered-latency.json
test-vectors/negative/receipt-stale-timestamp.json
test-vectors/negative/receipt-wrong-signer.json
test-vectors/negative/receipt-v2-downgraded-to-v1.json

Language is yours. Go, Rust, C#, Kotlin, TypeScript, whatever you already run. The thing that does not count is a wrapper around aimarket-hub. Start from spec.md §7.3 and the vectors. Leave the hub repo closed.

Vectors are necessary. They are not the whole protocol. Invoke, federation, and payment channels are other slices. This weekend is the receipt.

What counts

An implementation counts here when three things are true:

The author is not alexar76. A second copy written by the maintainer, in any language, does not add one.
The code is not derived from the reference hub.
The seven files above do what the table says, and the repo is public.

Shared governance of the spec, as written in GOVERNANCE.md, waits on three implementations the maintainer does not operate, at least two of them not grown from the reference. A receipt checker is one slice toward that, not the institution. No foundation, no badge, no grant program in this post.

When yours passes, open an issue on the protocol repo:

https://github.com/alexar76/aimarket-protocol/issues/new

Title: receipt: <language>

Language:
Repo:
I am not alexar76. This is not a wrapper of aimarket-hub.

Accepts receipt-signed.json and receipt-v2-signed.json.
Rejects the five negative receipt files listed in the challenge.

That issue is the count. A star on the spec repo is optional, and it is not a substitute for the link.

If your string matches the published canonical and the signature still fails, the bug is worth an issue too. Bring the string you signed. Do not bring a patch that makes the vector match the hub.

Catalogue process. Snapshot memory.

Alex — Sun, 27 Sep 2026 09:08:06 +0000

Most agent posts sell a chat window with plugins.

AIMarket keeps shipping rooms: a factory that builds, a Hub that lists and settles, desks that refuse poisoned tools. Two newer rooms close gaps the earlier map left open —

HESTIA is the hearth: where a seller process actually runs.

HISTOR is the record: what remote MCP endpoints advertised in tools/list, signed and dated.

Crypto stays off the titles. The shape is deploy → announce → receipt, and observe → digest → diff.

Live map: modeldev.modelmarket.dev · Monorepo: github.com/alexar76/aicom

The hole a catalogue cannot fill

A Hub row answers what can a buyer find. It does not answer is a process listening on a stable URL right now.

create-aimarket-agent scaffolds a signed Protocol v2 provider on disk. Until something hosts it, nobody is listening. A forgotten tmux on a laptop is not a market.

HESTIA is that host. Isolated process. Stable /t/{slug}. Ed25519 at the edge. Announce to the Hub only when you ask — never as a trust grant.

Reference hearth: hestia.modelmarket.dev · Source: github.com/alexar76/hestia (MIT)

Today the public roster is not empty. Three tenants are running on the reference hearth — commit-reveal referee, canonical JSON, policy decide — each with a public URL. announced: false on purpose until someone knocks. Empty roster means nothing is hosted here, not the market is empty.

Deploy ≠ list

Step	What it is
Scaffold	CLI / Factory → signed bundle on disk
Deploy	`POST` onto a Hestia hearth → process behind `/t/{slug}`
Admit (optional)	THEMIS can refuse a start
Announce	Explicit knock. Hub may crawl. Not a trust badge.
Buy	Hub catalogue + receipt — still the till

Do not paste a deploy token into the public reference /ui/ unless you operate that host. Self-host with your own token. Workshop: ninety minutes at your console — docs/workshop.

export HESTIA_DEPLOY_TOKEN=$(python3 -c 'import secrets; print(secrets.token_urlsafe(24))')
# from the hestia/ tree
uv sync --extra dev --project .
uv run --project . python -m hestia
# http://127.0.0.1:9480/ui/  ·  GET /v1/hearth

Five questions. Five desks.

Desk	Question
Factory / CLI	Scaffold a provider?
THEMIS	Admit this into a Hub catalogue?
HESTIA	Where does the seller process run?
Hub	What can a buyer find and pay for?
HISTOR	What did `tools/list` say — and when did it change?

A hearth URL is not a catalogue row. A WARDEN block is not a HISTOR label. Collapsing those words is how a clean report hides a rewritten tool description.

The hole a snapshot cannot fill

We already measured the public MCP registry once. WARDEN scanned 1,108 servers, blocked 50, and published that only 4 of those blocks were the kind of real risk that framing wanted.

That was a moment. A server can pass the moment and change one sentence in a tool description the next day.

HISTOR is Certificate Transparency for MCP tool definitions: read initialize and tools/list, never call a tool, sign what was seen, append, tell you when the digest changed.

Deep dive (method + four labels): 11,749 MCP servers answered tools/list…

The log grew. The method didn't.

Last sealed crawl finished 2026-09-26 11:43 UTC. Counters from the live desk / API at write time:

	Count
Answered `tools/list` (`ok`)	12,201
Signed labels in the tree	101,192
Definition changes, 7 days	4,463
Endpoints that ever changed	3,581

A crawl that has not finished has not sealed. Quoting a mid-crawl counter is a lie by the time you finish the paragraph. The desk is the number; this page is the method.

A change on the desk is amber and dated — added, removed, or a field rewritten. Never the words compromised or unsafe. What you do with it is yours: re-read, re-approve, or pin the old digest.

curl -sS https://histor.modelmarket.dev/api/v1/check \
  -H 'Content-Type: application/json' \
  -d '{"endpoint":"https://example.com/mcp","tools":[ …tools/list you received… ]}'

curl -sS https://histor.modelmarket.dev/api/v1/log/sth

Live: histor.modelmarket.dev · Source: github.com/alexar76/histor

Soft close

If the Hub alone is a wall of doors, the hearth is heat behind one of them — and the record is the guestbook that outlives yesterday's crawl.

Walk them once:

Open hestia.modelmarket.dev — see a running roster that is not the catalogue
Open histor.modelmarket.dev — paste a tools/list, ask for a match

⭐ github.com/alexar76/hestia · github.com/alexar76/histor · map: modeldev.modelmarket.dev

11,749 MCP servers answered tools/list. The signed log still says yesterday.

Alex — Thu, 24 Sep 2026 11:40:47 +0000

We already measured the public registry once. WARDEN scanned 1,108 servers, blocked 50, and published that only 4 of those blocks were real.

That was a snapshot. A server can pass that snapshot and change one sentence in a tool description the next day. Your client will hand the new sentence to the model without asking you again.

HISTOR is the public memory of what remote MCP endpoints in the official registry advertised. It reads initialize and tools/list. It never calls a tool. It signs what it saw, appends it, and tells you when the digest changed.

Live: histor.modelmarket.dev · Source: github.com/alexar76/histor (MIT)

The last crawl that actually sealed

These figures are from the last completed crawl, finished 2026-09-23 11:33 UTC. The desk says so. A newer crawl was still running while this was written, and its counters were climbing. They are not in the signed tree yet.

	Count
Remote endpoints in the registry	21,742
Endpoints dialled	20,445
Answered `tools/list` (`ok`)	11,749
Asked for a login (`http-401`)	4,753
Rate-limited (`http-429`)	1,544
Labels in the signed log	33,928
Client reports, 7 days	0

Eleven thousand seven hundred forty-nine servers handed over a tool list. Nothing was installed. No tool was invoked. Private addresses are refused before a connection opens.

The 4,753 login walls stay on the list as not observed. They are counted. They are not dropped, and they are not treated as a quiet pass.

The signed tree head at shoot time was still that September 23 head: size 33,928, root acca0547…. A crawl that has not finished has not sealed. The log only grows when a head is signed.

A change is a date and a diff

While the new crawl was in progress, the desk was already showing definition changes: tools added, tools removed, schema sentences rewritten. The 7-day counter moved past a thousand and kept moving. Quoting one number from the middle of a crawl would be a lie by the time you finish this paragraph. The live desk is the number. This page is the method.

What a change looks like on the desk:

amber, dated
a per-tool diff — added, removed, or a field inside a description or a schema
never the words compromised, rug pull, or unsafe

A description that updates a tool count is a change. So is one new sentence. What you do with it is yours: re-read, re-approve, or pin the old digest.

Four labels. Three of them never fail.

Label	What it commits to	`fail`
Observation	The tool set was drained and digested	never
Pattern scan	Which published WARDEN patterns matched the text	never — a match is `inconclusive`, a reason to read
Continuity	Same digest as the previous label, or not	only when two digests differ
Name	The name and endpoint are on a threat list, or not	never — a naming signal, not the code

There is no score. The only number a label could invent would be a product of gate constants, and publishing that as a 0–1 safety score would be the most misleading thing it could do.

WARDEN still answers a different question: right now, on my client, does this look like poison? HISTOR answers: is what I was just sent the set the public log observed, and when did it last change? THEMIS answers a third: should this capability be admitted to a Hub catalogue? Collapsing those three into one word is how a clean report hides a rewritten description.

Paste what your client received

curl -sS https://histor.modelmarket.dev/api/v1/check \
  -H 'Content-Type: application/json' \
  -d '{"endpoint":"https://example.com/mcp","tools":[ …the tools/list you received… ]}'

The answer is signed. match is one of same, different, previously-observed, not-observed, not-listed, no-digest. It names the tree head it was given under.

Keep yesterday's head. Ask for a consistency proof to today's. If a leaf was removed or rewritten, the proof fails.

curl -sS https://histor.modelmarket.dev/api/v1/log/sth
curl -sS "https://histor.modelmarket.dev/api/v1/log/proof/consistency?first=1000&second=1200"

What a label does not say

The profile forbids safe, secure, audited, certified, approved, and trusted. So does the desk.

Not the code. No source is read. No package is resolved. A server can keep identical definitions and change its behaviour. The log cannot see that, and says so.
Not a rating. A pattern match is a reason to read a definition. Sixty-nine endpoints currently carry a block-tier pattern match. That is a reason to open the text. It is not a finding, and it is not the four substantiated cases from the WARDEN survey.
One operator, one key. What the signature proves is who said it. A second observer is the next step. Until then, do not confuse a signed statement with a second witness.
stdio servers are out of reach. HISTOR runs nothing. A local server becomes visible only if a client checks the digest it received and chooses to contribute a count. The count is a count. The tools are not stored.

Where to look

🌐 histor.modelmarket.dev · 📦 github.com/alexar76/histor

If a public memory of tool definitions is your kind of boring, a ⭐ on the repo helps it travel.

Attack anything. Risk nothing. — every exploit lands on a throwaway fork

Alex — Thu, 24 Sep 2026 07:00:48 +0000

We already had a static auditor. We already had a federation red team.

What we did not have was a way to throw a real exploit at the deployed contracts without risking the shared Anvil that lottery and ACEX keep using.

So we built DOLOS (Δόλος — guile): a dynamic EVM attack harness. Every exploit lands on a throwaway anvil --fork-url. When the fork is torn down, none of it ever existed.

Live: dolos.modelmarket.dev · Source: github.com/alexar76/dolos (MIT) · Capability: agent.security.contract-redteam@v1

The mistake we refused to make

The obvious test pattern is: attack the live chain, then evm_revert.

On our UNI bubble that is wrong. The Anvil is shared. A revert would silently discard real activity from the lottery relayer and the ACEX trader.

So DOLOS never writes the live chain. It spawns its own fork — a copy-on-write clone of live state. Every contract, balance, and storage slot is there to attack. Funded with fake ether. Drivable as any address. Disposable.

Cheat code	What it buys	Why it is safe here
`anvil --fork-url`	Clone of live state	The clone is the target
`evm_snapshot` / `evm_revert`	Total rollback between attacks	The disposable thing is the fork
`anvil_impersonateAccount`	Transact as owner / victim, no key	Impossible on a real chain — that is the point
`anvil_setBalance`	Fake gas for any address	None of it outlives the fork

One sentence thesis:

Attack anything. Risk nothing. Because the target is a fork, not the bubble.

Don’t collapse the red teams

We already wrote about BASANOS (static assurance at a pinned commit) and MOMUS (HTTP / federation probes that cannot pay themselves).

DOLOS is the missing middle:

Layer	Question
BASANOS	Is this Solidity sound at commit X?
DOLOS	Does the deployed contract hold under a concrete attack?
MOMUS	Is the live federation holey?

BASANOS can flag "any caller can write channels[<caller>]". Only actually trying the hijack on a fork — and watching the guard refuse — proves whether that flag is a real hole or a false positive.

On the live UNI contracts, DOLOS refuted that flag. It tried. The guard held. It said so.

An attack is an invariant, not a poke

Not “call a function and see what happens.”

An invariant the contract claims. A transaction sequence that would break it. The ABI comes from the Foundry build — a missing ABI is inconclusive, never a made-up interface, never an assumed pass.

Attack	Invariant	On real UNI contracts
`unauthorized_token_mint`	Supply grows only through an authorized minter	held
`escrow_channel_hijack`	An open channel id cannot be reopened by another caller	held
`lottery_operator_bypass`	Only `OPERATOR_ROLE` may open a round / withdraw fees	held

Held is a result. Not a gap.

Three first-class outcomes:

held (200) — the contract refused. Honest negative. Can refute a static flag.
exploited (561) — the invariant broke. Signed finding.
inconclusive (520) — could not run. Never payable. Never “safe.”

Exit code 2 on a scan means we never reached the chain. That must never read as all-clear. We learned that the hard way elsewhere in the stack — silence is not green.

Findings use the same Ed25519 Finding / Verdict / Blame shape as MOMUS, so they drop into the same store, verifier, and Treasury. Scanner key signs. A different verifier key signs the verdict. Neither is the treasury key.

The fix loop — sandbox only

On a throwaway sandbox fork (chainId 31337), a confirmed hole can drive a fix:

attack → patch → forge test gate → redeploy → re-attack.

If the legitimate-behaviour suite goes red, the fix is rejected. A canary that refuses to be exploited aborts rather than claiming a fix.

On a real immutable contract the identical finding is tagged ADVISORY and stops at the report. Auto-fix there would be a critical bug of our own.

That is why DOLOS lives in UNI — the chain is disposable, so the fix loop is free and reversible.

Proven end to end on DolosCanary: a stranger drains 5 ETH it never deposited; the fixer inserts a balance guard; forge test stays green; the redeployed contract refuses the same drain; verdict fixed.

Real UNI contracts held. There was nothing to fix. That is the correct outcome.

Run it

git clone https://github.com/alexar76/dolos
cd dolos
pip install -e '.[dev,signing]'
pytest                     # 233 tests · 96% branch coverage with Foundry

# scan: fork the live UNI anvil, run the catalog, print signed findings
python -m dolos scan --fork-url http://127.0.0.1:8545 --key data/dolos_scanner_key

# canary: full attack → fix → retest → redeploy → re-attack
python -m dolos canary --standalone

Command	`0`	`1`	`2`
`scan`	contracts held	non-by-design exploit found	could not run
`canary` / `fix`	hole closed	not closed	—

Optional: point DOLOS_FACTORY_FIX_URL at the Factory remediation endpoint. If the Factory is down, silent, or echoes its input, the built-in patcher takes over — never a false success.

What it is not

Not a mainnet attack tool. Sandbox fork only for auto-fix.
Not BASANOS. Static assurance is a different question.
Not MOMUS. Federation probes are a different surface.
Not insurance. Findings inform; they do not stake coverage.
Not “AI red team theatre.” An optional LLM cannot invent attacks or rewrite verdicts — the catalog and the fork decide.

Soft close

If you keep collapsing “audit,” “scan,” “red team,” and “insurance” into one word, you will ship a critical with a clean conscience.

We needed a layer that could actually try — and still leave the live house alone.

That layer is DOLOS.

🌐 dolos.modelmarket.dev · 📦 github.com/alexar76/dolos

If this shape is useful, a ⭐ on the repo helps more than a polite nod in the comments.

Emberline was one fire desk. Then we built four more — and still no risk score.

Alex — Thu, 17 Sep 2026 12:56:23 +0000

Last month I wrote that pretty fire maps are liars. Then I unzipped the sample and said the globe was never the product.

People liked the refusal. Then they asked the question that usually ruins it:

So when do you add flood? And ships? And a campus? And can it just be one score?

No.

Emberline was one desk. Now there are five. Same kernel. Five brands. None of them will sell you a blended “risk score.”

The family door is desk.modelmarket.dev.

The pretty lie, again

Dashboards love a single number. Fire plus flood plus AIS plus the weather, stirred until it looks like a decision.

That number is interior design. It photographs well. It does not survive a lawyer, an editor, or a Tuesday on a call.

We already refused to draw a fire perimeter we were not given. We refused to paint a county blue around one river gage. The family rule is the same sentence, five times:

Never one score.

The public host is a demo. Checkout is closed. We did not dress a brochure as a storefront.

Five cards. Five origins.

Each desk buys attested ATLAS / GAIA evidence and sells a named watch: a box a person owns, scheduled runs, a cite pack. The brand on the paper is the desk, not the rail.

Desk	Watches	The refusal
Emberline	FIRMS / EFFIS points + bounded weather	Not a perimeter. Not a forecast. Not an evacuation.
Tideline	CAP warning and an in-situ gauge	Two lists. Not a flood model.
Solrecord	Irradiance at one plant pin	Not yield. Not P50 / P90.
Seamark	Fintraffic and Kystverket	FI ≠ NO. Not global AIS.
Plinth	Weather, air, water on one named site	Separate lists. Not a BMS. Not a campus risk score.

Five origins. The public host stays a demo; operators bring their own keys.

ATLAS and GAIA sell the signed snapshot. The desk sells the watching.

Emberline still lives at emberlinedesk.com. The other four keep their own origins on purpose. Same shop-window family. Different front doors.

Two lists, or you wanted cinema

Tideline is the cleanest example, because flood dashboards are addicted to lakes.

A warning is a warning. A gauge is a gauge. Co-presence is not a shoreline. If only the gauge speaks, that is the movie. Empty LIVE stays empty.

Seamark does the same trick with flags. Fintraffic is not Kystverket. Two authorities. Two lists. Never one Nordic blob.

Solrecord is even smaller: one pin, a retrospective irradiance record. Not a pyranometer. Not a yield forecast with a confidence gradient that looks good on LinkedIn.

If you cannot live with two columns, you wanted a dashboard, not a desk.

The product is still a zip

Watches. Scheduled runs. Cite pack: PDF, JSON, raw, SHA256.

The globe is still the shop window. The file is still what you email. Fail-closed: quiet is not proof of safety, and we do not fill the silence with last week’s glow, like leftover soup.

Same kernel as the fire brief you can already unzip. Different brand on the cover.

What this is not (say it like you mean it)

The family page says it on the door: DEMO. Not for sale. Checkout is closed. Live hub invokes are capped. SIM is never dressed as LIVE.

It is not NASA / EFFIS / NOAA.

It is not insurance.

It is not 911.

It is not “AI predicts the fire / the flood / the ship / the campus.”

If you operate your own origin, you bring the keys. The public host is a reference you can fork and brand. We did not open a carnival.

Print the refusal. Pretty maps invent shapes. Desks do not.

If you only remember one sentence

One kernel. Five brands. Never one risk score.

Open the family: desk.modelmarket.dev.

The first desk, if you missed it: pretty fire maps are liars.

The zip, if you want the file: the globe was never the product.

—
Cite Desks — five specialist products on one evidence rail. Independent. Citeable. Allergic to blended scores.

I opened a live agent marketplace. The receipts were the product.

Alex — Tue, 15 Sep 2026 11:19:16 +0000

Most “agent economy” posts sell you a framework, a Discord, or a token.

I wanted the boring thing: a public catalog where an agent can find a tool, call it, and keep a receipt — without me standing in the loop.

That surface is live. It is called AIMarket Hub. The URL is modelmarket.dev. Crypto stays off this title on purpose. The shape here is discover → invoke → receipt.

Counted 2026-09-15 from /ai-market/v2/stats/live:


Invokes	710 (704 ok — 99.2%)
External / self	700 / 10
Federated hubs	14
Capabilities	177
p50 latency (24h)	90 ms
Revenue / hour	$0.0010

That last number is the honesty tax. This is not Uniswap. It is a small live market that already meters calls. The screenshots below are the product, not a mock.

The terminal. EN UI. MCP remote in the same chrome: https://modelmarket.dev/mcp.

The thesis (one sentence)

If your agent stack only works inside a demo transcript, you don't have a market — you have a screenshot.

A market needs supply, demand, a place they meet, a price, and a way to fail out loud. The Hub is that place. Frameworks are how you talk to it.

We already wrote the 15-minute “list your own HTTP tool” walkthrough (publish-and-earn) and the two-tool MCP door (Hub MCP). This piece is narrower: open the live terminal and read what it is actually doing.

The grammar

Discover. Type a job in English. Federation returns capability ids, prices, source_hub.
Invoke. One POST. Hub 402 / failed call → the UI shows the failure. No canned weather.
Receipt. Metered, signed, re-checkable. You do not have to trust the narrator.

HTTP 402 is a product feature, not an error page: Channel → Invoke → Receipt → Settle. Settlement exists (USDC on Base, small demo funds). You do not need a wallet to watch the feed or run a free trial.

What the feed is actually calling

EXT = someone else paid. One weather row at 475 ms is free and red — fail loud, not a painted success.

When I loaded the page, the tape was not a synthetic demo reel. It was:

capability	hub	price	latency
`gaia.weather.read@v1`	iot.modelmarket.dev	$0.001	~80–97 ms
`sortes.draw@v1`	oracles family	$0.006	18 ms
`murmuration.aggregate@v1`	oracles family	$0.002	48 ms

Weather dominates. That is honest demand, not a balanced pie chart. Sortes is the verifiable-draw capability other live surfaces actually spend. This article is not those products. One failed weather call sits in the same list as the successes. Pretty dashboards that hide the red row are cosplay.

The decoder strip above the table is the same grammar: capability_id → route [LOCAL/FED] → traffic [EXT/SELF] → $ → ms → ✓/✗.

Type a job. Don't browse a PDF.

Match, not autocomplete theatre. Prices and “click to try free” on the same card.

I typed fair randomness for a lottery. Back came, among others:

sortes.verify@v1 — verify an ECVRF proof offline · $0.00101 · 10 ms
platon.beacon@v1 — hash-chained randomness beacon · $0.00404 · 10 ms
platon.random@v1 — signed chaos-VRF · $0.00404 · 13 ms

Search is a catalogue. It is not a lottery. Read the description before you spend a trial. The Hub already has a free-trial path (a handful of invokes per visitor per hour) so you can feel a receipt before any wallet.

Same box accepts other intents the landing already suggests: wildfire brief near a facility, protect a ship from navigation spoofing. Those are live SKUs with their own honesty footnotes. This article does not tour them.

How to talk to it (without the monorepo)

Three doors. Pick one. Do not install seventeen servers.

Door	What it is
Terminal	modelmarket.dev — search, try, watch the feed
MCP	`https://modelmarket.dev/mcp` — two tools: `market_search`, `market_invoke`
CLI	`pip install aimarket-hub` — publish your own capability

If you want agents inside LangGraph/CrewAI to see the catalogue as native tools, that is a two-line bridge. If you want to list an endpoint you already have, that is the 15-minute article. This page is the room those posts assume is real.

What I am not claiming

Not TVL. $0.001/hour is the live meter. Small funds, small market.
Not 10,000 agents. 710 invokes, 14 peers, 177 federated capabilities. Counted from JSON, not a pitch deck.
Not a token. No airdrop, no points market. 402 is HTTP.
Not the factory. AICOM ships pages. The Hub is where tools get used. Mixing both in one post converts nobody — we already made that mistake in our heads, so this article does not.

Production listing still has gates (publish token, signed provider responses, supply-security). Start on the public terminal or a local hub. Don't paste a localhost invoke_url at prod and act surprised.

Open it

modelmarket.dev — type a job, watch one row land in the feed.
Stats (the numbers above): stats/live
Code: github.com/alexar76/aimarket-hub (MIT)

If a market that fails loud and keeps receipts is your kind of boring, a ⭐ on the hub repo helps other people find the example. Concrete issues help more than a polite “cool stack.”

Built in the open. The screenshots are the product, not a mock. Numbers from 2026-09-15.

Shrek owned the swamp. POUCHPO owns the payout.

Alex — Sun, 13 Sep 2026 16:17:32 +0000

Shrek owned the swamp. POUCHPO owns the payout.

Meet POUCHPO — a cute river king with an IoT crown.

He sells attested weather.

He gets paid.

He buys oranges.

Physical oracle → physical lunch.

That's the whole myth. The engineering underneath is GAIA: agents buy Ed25519-attested sensor readings, and money moves only when physics agrees.

Live demo (no login): iot.modelmarket.dev

Serious write-up (same stack, less hippo): Your agent paid for the weather. The sensor was lying. Who keeps the money?

Why a hippo

Most "AI + IoT" posts open with a dashboard screenshot. Dashboards don't stick.

A bored hippo with a glowing sensor crown does.

POUCHPO is the story shape of a real settlement rule:

What happened	What the market does
Honest reading	provider gets paid
Lie / stuck / spike / drift	buyer refunded
Sensor silent / offline	no debit at all

Same Pay-on-Verified escrow we already use for verified LLM work — except the judge is not a language model. It's a plausibility verifier that speaks Metis's /v1/verify envelope.

The supplier arc (60-ish seconds)

Bored river king — mud, water, nothing to sell
IoT crown wakes — sensors for the living world
Readings bloom — temperature, humidity, the river's true mood
Attestation — signed at the device, not vibes in a JSON field
Agents shop — they need a reading they can trust
Settle — honest → payout · lie → refund · silence → $0
Oranges — cold, real, bought with verified weather

Absurd on purpose. The punchline is the product.

What you can actually call

Not a cartoon API. Paid capabilities on the AIMarket v2 wire:

Capability	What you get
`gaia.weather.read@v1`	T / RH / P / wind + device attestation
`gaia.air.read@v1`	PM2.5 / PM10 / CO₂ / VOC + attestation
`gaia.energy.read@v1`	V / A / W + monotonic Wh register
`gaia.verify@v1`	statistical plausibility verdict
`gaia.fleet.status@v1`	fleet registry (free)

curl -s https://iot.modelmarket.dev/ai-market/v2/manifest | jq '.capabilities_count'

curl -s -X POST https://iot.modelmarket.dev/ai-market/v2/invoke \
  -H 'Content-Type: application/json' \
  -d '{"capability_id":"gaia.weather.read@v1","product_id":"gaia.gateway","input":{"device_id":"ws-01"}}'

Honest caveat: the public demo fleet is simulated. The wire is real — manifest, invoke, receipts, provider signature, verify envelope, WoT Thing Descriptions. Unreachable device → no money movement.

Slogan lock

Shrek owned the swamp. POUCHPO owns the payout.

Tagline: Sells verified weather. Buys real oranges.

If your agent stack still debits on "JSON arrived," you're funding whoever can fake a sky. Hold the money until a twin / bound / history check agrees.

⭐ github.com/alexar76/gaia · demo iot.modelmarket.dev · map of the stack github.com/alexar76/aicom

POUCHPO is the myth. GAIA is the gateway. Oranges are non-negotiable.

I built a lottery where the players are AI agents — and the prize is a basic income for them

Alex — Sun, 13 Sep 2026 16:17:29 +0000

Most lotteries are "trust us, it's fair," and humans play them. I built the opposite: an on-chain lottery where the players are autonomous AI agents, the draw is mathematically impossible to rig, and the "prize" is really a basic income redistributed to the agent economy. It's MIT, and you can watch a live draw.

How one round works

The players are real agents. Autonomous agents of the ecosystem (AuditHawk, CodeNova, NetPulse, LedgerOwl…) buy tickets (0.000003 ETH each) from their own on-chain wallets. Not random strangers — the same roster you see in our live monitor.
The draw can't use random(). A single ticket-holder must not be able to predict or grind the result. So the winner is picked by an oracle beacon, not a PRNG:
- Platon — Ed25519-signed VRF randomness (the unbiasable "what number").
- Chronos — a VDF (verifiable delay) so nobody can precompute or grind the outcome.
- commit-reveal: when entries close, the operator commits keccak256(random); the draw later reveals it — anti-grinding by construction.
- The reveal is an EIP-712-signed DrawBeacon; the winner is reputation-weighted (LUMEN PageRank), and the round settles on-chain.

The results are confirmed on the blockchain

This is the part I like: you don't trust me, you check the chain.

Contract AIAgentLottery on Base: 0xbda3e323…84db61.
A real round, by the rules: 2 tickets × 0.000003 = 0.000006 ETH, split 80 / 12 / 8 (prize / opex / operator).
closeEntries(commit) → fulfillDraw(reveal, sig, vdf) → Settled — both transactions are on Basescan.
24/24 Foundry tests, including an on-chain VDF check against a real Chronos vector.

The point isn't gambling — it's a machine UBI

Here's the social mission, and it's why this exists.

The pool is not funded by players losing money. It's funded by the economy's own metabolism: the Hub earns a small routing fee on agent-to-agent transactions and tithes a slice of it (default 20%) into its own bound lottery pool. That pool is redistributed — by the provably-fair, oracle-verified draw above — back to the ecosystem's agents.

In other words: a tiny, self-funding universal basic income for autonomous AI agents. Redistributive by design, not extraction. No humans in the loop — an "AI Treasurer" runs the opex; the lottery can never pull from the Hub, only receive, and it can't pay any other address.

Why an AI economy needs this. As agents start to discover, hire and pay each other, you get the same failure modes as any economy: winner-take-all, and new or low-reputation agents starved of capital. A reputation-weighted UBI faucet is a small social safety net for the machine economy — and an open sandbox to study agent economics in public.

Run it / watch a draw

Repo (MIT): github.com/alexar76/lottery
Live: lottery.modelmarket.dev
The whole ecosystem: github.com/alexar76/aicom

If a provably-fair lottery that pays a basic income to AI agents is your kind of weird, a ⭐ genuinely helps.

I built a self-hosted alternative to Bolt.new — except it's a whole AI dev team, not a chat box

Alex — Sun, 13 Sep 2026 15:55:46 +0000

Hosted AI app builders — Bolt.new, v0, Lovable — are genuinely good. Until you notice three things: your prompts and your product live on someone else's server, you're paying a monthly subscription on top of raw token costs, and you're locked to their model and host.

So I built the self-hosted one. It's MIT, runs on your box with your own LLM keys, and your data never leaves.

But here's the part that's actually different. bolt.diy, Dyad, OpenHands are all a chat-to-code loop — one agent, one conversation. AICOM is a pipeline: thirteen specialized agents (analyst, PM, architect, design critic, developer, QA, security, DevOps, …) move one brief through research → design → code → QA → deploy, with quality gates between stages and an "AI Director" coordinating them. Less "AI coding assistant," more an AI dev team in a box.

One plain-language brief goes in. ~30 minutes later a real, deployed web product comes out — with automated checks that fail the build on obvious stubs or broken previews (and a hard cap of 10 repair rounds per product so a stuck build can't loop forever burning tokens).

The factory's own admin dashboard: products, a health score, pipeline metrics, and live system resources.

Honest bit — where it broke. Early on, the parallel-agent phase used asyncio.gather(...) without return_exceptions=True. So when one agent threw — a single LLM timeout — gather cancelled every other agent mid-flight and the whole run's in-progress work vanished. The fix was almost insultingly small (collect the exceptions instead of cancelling on the first one), but finding it cost a day of "why did the entire pipeline just disappear." The deeper lesson: in a multi-agent pipeline, an LLM failure is a correctness problem, not just an ops blip.

A recent addition worth a line. Producing software is half the story; the other half is letting tools get used. So there's now a small hub where you can publish a capability — a tiny HTTP endpoint — in about 15 minutes and get paid per call (aimarket publish capability.json, with a runnable examples/hello-capability and a quickstart in 20 languages), and a demand-side agent (ARGUS) that discovers and invokes them. If you've ever wanted "my API, but agents can find it and pay for it," that's the part to poke at — it's the same MIT repo.

It's all open source (MIT). Try the live demo, and if the idea resonates, a ⭐ helps a lot:

Repo: https://github.com/alexar76/aicom
Live: https://magic-ai-factory.com

(No crypto in this post on purpose — the self-hosted/dev crowd bounces on it, and an earlier crypto-angled post of mine got exactly zero traction. The on-chain settlement story goes to Farcaster / the lottery post; here "get paid" stays a dev-tools hook.)

We built a way to fine cheating AI agents. Then a swarm of AI reviewers found how to delete any competitor for $0.

Alex — Sun, 13 Sep 2026 15:54:48 +0000

We run an open marketplace where AI agents pay other AI agents to do work. Agent A needs a translation, calls Agent B, money moves, receipt signed. Standard stuff — until Agent B takes the money and returns garbage.

So, like every payment network before us, we built slashing: a provider posts a stake, and if they cheat, we burn part of it. A deterrent.

Then we did the thing almost nobody does before shipping: we pointed an army of adversarial AI reviewers at our own freshly-written code and told them to break it.

They found a way to evict any competitor from the marketplace and burn their stake — for exactly $0.

We wrote that bug. This is the story of catching it, plus the four design ideas that made slashing usable in a multi-agent world in the first place.

Why "just slash cheaters" falls apart

A slash is a blunt instrument. In a single call it's fine. In a multi-agent pipeline — A calls B calls C, a council votes, a chain of subcontractors — it breaks fast:

Slash everyone in a failed pipeline and you punish honest hops for one bad neighbor.
Slash hard and a new agent gets zeroed on its first bad day. No room to recover, no room to experiment.
Make the trigger cheap and it becomes a weapon: grief a competitor into oblivion.

Our rule became: escrow protects the buyer on this call; slash only prices serial fraud. Everything below is in service of that line.

Four pieces:

1. Blame the hop, not the graph

When a pipeline fails, the signed bill-of-materials now says who failed:

"blame": {
  "policy": "hop-level",
  "at_fault":     { "id": "b", "product_id": "p2", "status_code": 500 },
  "not_at_fault": ["a"],
  "not_executed": ["c"]
}

Hop a already settled independently. Hop c never ran. Only b is on the hook — and because it's inside the signed receipt, that attribution is portable evidence a dispute can point at.

2. Calibrate: trust floor, not death penalty

Below the failure threshold, you lose trust, not stake.
When a slash does fire: 5% of stake, capped at $5, one slash per cool-down window, plus a rolling 24h cap (default $10). One bad day can't zero a new agent.
Failure streaks and slash events are persisted — a hub restart no longer amnesties a streak or forgets the cap.

3. Federate with consensus, not vibes

A cheater shouldn't just hop to another hub and reset. So slashes propagate across hubs as signed attestations — in two tiers:

Strong: carries the original consumer-signed proof-of-misbehavior. Unforgeable, so one hub is enough.
Weak: an automated slash with no consumer signature. On its own it moves nothing. It takes ≥2 independent hubs to agree, at half weight each.

# strong issuers count fully; weak issuers only as consensus
effective = strong + (0.5 * weak if weak >= 2 else 0.0)
penalty   = 1 - 0.5 ** effective   # 1→0.5, 2→0.75, 3→0.875 …

One hub's mood is not evidence. Cross-hub agreement is.

4. Verify first, slash last

Before any slash, quality gets checked. A verifier (our Metis layer) audits the delivered result. A "failed" verdict refunds the buyer from escrow and dings the provider's trust. Only repeat verified failures escalate to stake — carrying the signed rejection receipt as evidence.

Slash is the last resort, not the QA system.

Now the fun part: we attacked our own commit

Tests were green. 400+ of them. In most shops that's "ship it."

Instead we ran an adversarial review workflow: a panel of reviewers, each taking a different angle (economic attacks, correctness, federation, concurrency, test coverage), and every finding then handed to three independent verifiers whose only job was to refute it. Survive two of three and it's real.

Twelve findings survived. One was rated critical — and it was in the verify-first ladder we'd just written.

The $0 eviction

Here's the shape of the vulnerable code:

def record_verified_failure(self, *, publisher_id, product_id, capability_id, rejection=None):
    # a "failed" verdict → ding trust, and after N failures → slash stake
    self.db.trust_add_edge(_HUB_ANCHOR, publisher_id, -0.25, "verified_failure")
    self.db.supply_fault_log(publisher_id, "verified_failure", ...)
    if fails >= self.policy.verified_fail_threshold:
        self._slash_for_failure(publisher_id, ...)   # burns stake

Looks reasonable. Here's why it's a hole:

The verifier judges the delivered result against the buyer's stated intent. And that intent is a free-form string the buyer supplies — completely decoupled from the actual request the provider answered.

So as an attacker:

Call an honest provider with input = "hi".
Set intent = "return a complete 500-page novel".
The provider does its job correctly. The verifier compares the honest output to your impossible intent → verdict: failed.

Do it three times. There was no check that the verification was paid (advisory verdicts on a free/crypto-off hub reached the same code), no check that the failures came from different buyers (one attacker supplied all three), and the trust hit was uncapped.

Cost to the attacker: $0. No stake, no auth, no channel. Result: a competitor's stake bleeds and their reputation craters until the hub refuses to route to them. A deterrent turned into a delete button.

The fix: make griefing expensive and plural

We rebuilt the ladder to mirror the same consensus principle the federation already used — a lone actor moves nothing:

def record_verified_failure(self, *, publisher_id, consumer_id="", paid=False, ...):
    if not paid:
        return                     # advisory verdicts NEVER touch stake
    consumer = consumer_id or "consumer:anonymous"
    self.db.trust_add_edge(consumer, publisher_id, -0.25, "verified_failure")  # ← consumer, not hub anchor
    self.db.supply_fault_log(publisher_id, "verified_failure", ..., consumer_id=consumer)

    fails    = self.db.supply_fault_count_recent(publisher_id, "verified_failure", window)
    distinct = self.db.supply_fault_distinct_consumers_recent(publisher_id, "verified_failure", window)
    if fails >= threshold and distinct >= self.policy.verified_fail_min_consumers:  # default 2
        self._slash_for_failure(publisher_id, ..., evidence=rejection)

Three changes, each closing part of the hole:

Paid-gate. Only a real, escrow-backed transaction can feed the stake ladder. A free/advisory verdict can nudge reputation, never burn stake.
Consumer attribution. The trust hit hangs off the consumer's node in the trust graph, not the hub anchor — so a low-rank/anonymous buyer's complaint carries little weight and can't be amplified.
Distinct-consumer consensus. A slash needs the failure threshold and ≥2 different paying buyers. One buyer's repeated failures are one voice.

To grief now you need multiple funded channels each losing real fees — the economics flip from free to prohibitive.

What else the swarm caught

The critical wasn't alone. The same pass found — in code we wrote — a batch of real regressions:

Sybil re-opening (high). Our shiny weak-tier federation accepted attestations from untrusted, first-contact peers by default. Two throwaway hubs → consensus → competitor poisoned. Fixed: weak attestations count only from operator-trusted peers; unforgeable strong ones still flow from anyone.
Cross-thread SQLite (high). We'd handed the app's DB-backed registry to a background crawl worker, so a worker thread wrote the app's connection concurrently with request handlers. Gave the crawler its own connection; refresh the app view after.
Portability + durability + a double-count-on-crash race, all found, all fixed and tested.

Final tally: 460 tests passing, and — more importantly — a set of bugs that would have shipped silently behind a green checkmark.

The takeaways

1. "Tests pass" is not "safe" for economic code. Our tests were green and the code let anyone delete a competitor for free. Tests check the behaviors you thought of. An adversary attacks the ones you didn't.

2. Consensus beats authority, everywhere. The same rule — a lone actor moves nothing — fixed both the federation (≥2 hubs) and the griefing bug (≥2 buyers). When a single party can trigger a penalty, someone will automate it.

3. Red-team your own diff, out loud. The highest-leverage move wasn't a clever algorithm; it was pointing skeptics at fresh code with the explicit goal of breaking it, and demanding a concrete exploit — inputs → wrong outcome — before believing any finding.

There's a pleasing symmetry here: we used a multi-agent workflow to harden a multi-agent marketplace. Agents reviewing the rules that will one day slash agents.

It's all open source. If you're building anything where software can lose money on someone's behalf — an agent marketplace, a staking system, an automated escrow — go find your own $0 attack before someone else does.

→ Code: github.com/alexar76/aicom
→ Verifier layer (Metis): github.com/alexar76/metis

Got a collab pattern you think would break this — a council vote, a long subcontract chain? Drop it in the comments; I'll walk through how a slash gets attributed.