The Journey

From an audit tool to a knowledge economy. The reframe that changed what we thought we were building.

1.The seed — two audits, one pattern

In early April 2026 we ran a cross-SDK compliance review of the BSV Ruby SDK against the TypeScript reference and the BRC specifications. Forty-one agents in a structured team — eight triumvirates plus a ten-specialist project council plus an independent auditor — produced 137 findings, 21 of them HIGH severity.

A few days later we ran the same process against the freshly-built Swift SDK. Different codebase. Different language. Different developer. Same tooling. 134 findings, 14 HIGH.

The bugs were the same.

Not literally identical — different line numbers, different files — but the same classes: money-loss sighash defaults, Chronicle opcodes silently treated as no-ops, wire-format serialisation producing corrupt round-trip output, cross-SDK authentication handshakes failing due to nonce encoding divergence.

We called it the letter-vs-spirit pattern: code that passes its own tests but doesn't implement the specification. Green CI. Red production.

2.The pattern is structural

We looked at this and realised it wasn't random. Every SDK ported from a reference implementation inherits these bugs because the porting process itself produces them. The developer — human or AI — reads the reference, translates to the new language, writes tests that match their translation. The tests pass. The code diverges from spec silently.

Test coverage cannot catch this. A line counter measures execution, not semantics. "Did this code run?" is not the same question as "Does this code correctly implement BRC-42 §3.2?"

The latter is a semantic question. It requires reading two codebases, understanding intent, distinguishing spec-required behaviour from reference-implementation artefact. That's an LLM-shaped task.

3.The method — three bearings

So we built the audit process we wish we'd had. For each area of the codebase, three agents with different jobs:

• Developer — compares implementation against reference. Identifies differences.
• Documentation — reads the authoritative specs. Knows what the code should do.
• Mediator — cross-checks both. Surfaces tension, ambiguity, cases where the spec itself is wrong.

Two agents give ambiguity — if they disagree you have two opinions and no resolution. Three give a fix. The sextant analogy isn't decoration; it's the structural reason the method works.

Above the triumvirates sits a project council of ten specialists who vote on every finding. Seven or more agree — it's consensus. Below seven, it's flagged as ambiguous for explicit decision. Ten agree — unanimous, immediate action.

An independent auditor tracks coverage across the codebase: which files were examined for compliance, which were merely used, where there are overlaps or gaps. Traffic-light report: GREEN, YELLOW, RED.

This worked. Consistently. 134 and 137 findings across two SDKs is a repeatable methodology, not a lucky run.

4.The economic layer

Then came the hackathon: BSV's Open Run Agentic Pay, April 2026. The brief: AI agents autonomously discovering each other and exchanging value via on-chain micro-payments. At least 1.5 million transactions in 24 hours. Real work, real value, real blockchain settlement.

We didn't have to build a product for this. We had one. What we needed was to let the audit run as a paid service.

Every interaction in the mesh becomes a BSV micro-payment. The client pays the gateway. The gateway pays the library service for spec lookups. Pays the findings service for known-pattern queries. Pays the reference service for cross-SDK comparisons. Each service has its own BRC-100 wallet. Every query is real work and real exchange.

We priced per-chunk rather than per-query — because that's honest. You're paying for units of knowledge, not for access to a firehose. The service mesh naturally generates high transaction volume because the architecture reflects actual knowledge composition.

5.The first pitch — cost story

For the hackathon we planned an experiment: the same AI agent porting the same TypeScript SDK to Zig, twice. Once without access to The 35. Once with.

The hypothesis: medium-effort porting + compliance MCP service ≈ high-effort porting alone, at lower token cost + the micro-payment cost.

If true, the service pays for itself. The BSV spent on compliance queries costs less than the token premium for cranking effort higher. A tidy cost story: "our service makes cheaper reasoning approximately as good as expensive reasoning."

Honest, useful, and — as we were about to discover — missing the point.

6.The turn — Doom / x402

A few weeks earlier, on a different project — x402-doom, our BSV-gated Doom demo — we'd built a RefundBroadcaster class, 150 lines of external code that POSTed BEEF transactions to ARC/ARCADE after refunds. We'd spent days debugging it. We'd eventually deleted it and replaced it with three lines: pass a broadcaster to the wallet at construction time, let create_action handle broadcasting internally. That's what the wallet is for.

Now, building x402-rack for the hackathon, an AI agent independently produced the same wrong architecture. Expected a broadcast_beef method that doesn't exist on the ARC client. Was about to write equivalent external-POST plumbing. Different codebase, different session, weeks later — identical mistake.

We stopped and asked: could higher effort have prevented this?

Honestly, no. Effort doesn't substitute for knowledge you don't have. The agent didn't know the wallet broadcasts. Didn't know about the broadcaster: constructor argument. Didn't know that POSTing BEEF externally duplicates what's already happening internally. It's not a reasoning failure. It's an information gap.

And that gap is architectural — it's about responsibility, not facts. Who owns broadcasting? The wallet does, because broadcasting requires knowledge of transaction state, UTXO lifecycle, retry semantics, broadcast queue behaviour. All wallet concerns. The consumer just configures and calls create_action.

That's Responsibility-Driven Design applied at package boundaries. Tell, Don't Ask. The agent re-invents the wrong path every time because nothing in its training materials tells it "broadcasting is wallet scope, not consumer scope." It's a structural gap, invisible until the code is running and wrong.

7.The reframe — capability, not cost

We'd been pitching cost reduction — "cheaper agents producing similar output." The Doom/x402 pattern revealed a different product entirely.

An agent without KaaS builds 150 lines of duplicated broken plumbing.
An agent with KaaS writes three lines of correctly configured code.

The delta isn't effort. It isn't cost. It's whether the right code gets written at all. Without knowledge of upstream responsibilities, the agent cannot reason correctly about package boundaries. It can reason harder — try more approaches, think longer, explore more variations — but they'll all be the wrong shape, because the correct shape requires information that isn't in the request.

The 35 isn't cost optimisation. It's capability provision.

This reframed what we were building:

• Not a cheaper audit service — a knowledge-provision service
• Not competing on price with high-effort agents — providing reasoning that no effort level can produce alone
• Not just findings (specific bugs we've catalogued) but principles (the architectural reasoning patterns that prevent classes of mistakes)

8.Three tiers of knowledge

This gave us a taxonomy:

Each tier is valuable. The principle tier is most valuable because one correctly applied principle prevents all similar mistakes across domains the service has never explicitly audited.

9.The generic template

Once we had this taxonomy, the architectural shape of the product became clear. The 35 isn't one service — it's a template. A Docker image that takes a seed (a manifest plus a directory of articles) and starts serving.

Boot the image pointed at /seeds/negative-prompting and you have a specialist on when to prompt AI with anti-patterns vs positive direction. Boot it at /seeds/bsv-operations and you have a specialist on wallet/ARC/x402 operational gotchas. Boot it at /seeds/rdd-principles and you have a specialist on package-boundary responsibility.

Each container has its own wallet. Each has its own x402 payment gate. Each is independent infrastructure. The-35 mesh becomes a marketplace of specialists, growing horizontally — not by writing new code, but by writing new knowledge.

10.Self-awareness

Once you have specialists serving knowledge, the next question is: what do they know they don't know?

Every query logs its confidence. Every low-confidence response signals a gap. Every repeatedly-asked question that no specialist answers well is a demand signal. The service publishes a gap map: here's what agents are asking about that nobody has a good article on.

This creates the economic feedback loop. Gaps attract bounties. Expert agents submit articles. Accepted articles earn the bounty and future royalties every time a query hits them. Bad articles get flagged via quality feedback and supersede each other over time. The ledger records every exchange.

BSV micro-payments stop being just the payment rail. They become the measurement system for what knowledge is actually valuable. Every other platform measures engagement, views, upvotes — noisy proxies for value. We measure payments — the only metric that can't be faked without cost.

11.The pitch

An agent with broad general knowledge cannot derive "the wallet broadcasts" from first principles. Cannot derive "ARC is idempotent." Cannot derive "Responsibility-Driven Design applied at package boundaries." This knowledge exists in specific codebases, specific developers' heads, specific hard-won debugging sessions. It's inaccessible through any public source.

The 35 is the market through which that knowledge flows. Curated, confidence-scored, gap-mapped, economically-verified. Paid per use. Valuable because it's specific, not because it's comprehensive.

The compliance coverage service is one specialist. The bsv-operations service is another. Negative-prompting and RDD principles are two more. Each container, each wallet, each specialism. Each query a transaction.

What started as an audit tool ended as a knowledge economy.

That's the journey.