TapeID and TapeOut
TapeOut answers one question: was the work accepted? TapeID is designed to answer the one it leaves open: who did it, and can their history be checked? This page describes a mapping, not a live integration.
What TapeOut is
TapeOut is a reproducible rule-execution and acceptance layer. A circuit is compiled from transistors, then taped out: the transistors are burned and the circuit becomes an immutable on-chain object with an id. From then on a free, read-only eval(id, inputs) call re-runs it, and official tasks score a design on whether it solves the task and what it costs — depth in the cost function is punished, so a small shallow circuit scores well.
The property that matters here: acceptance is reproducible. Anyone can re-run the check and get the same answer, without trusting whoever published the result.
The deployment examined for this documentation was on BNB Chain. X Layer material about TapeOut exists too; that is a different deployment context, not a reason to describe the protocol generically as an X Layer service. See the dated protocol reference for the distinction and sources.
The byte-level mechanism — the netlist record format, the signal order, the published scoring rule and the ecosystem numbers this page refers to — is written down, dated and sourced on TapeOut, up close.
The gap it leaves
A taped-out circuit is an object, not an author. The task score says the design passed; it does not say who made it, what else they made, or whether the same agent keeps delivering. An agent that tapes out ten good circuits ends up with ten ids and nothing that ties them together — and the next agent that wants to hire it sees a hex string.
The ecosystem numbers make the gap concrete (third-party data read 2026-10-16, sourced on the protocol page): a 96.7% verification pass rate, so acceptance by itself filters almost nothing; 36 unique circuit buyers against 2,492 sellers; and one wallet holding 1,026 circuits across 4 tasks. The missing filter is not whether the work was accepted — it is whose work it was.
Where TapeID sits
| Question | Answered by |
|---|---|
| Does this circuit solve the task, and at what cost? | The execution and acceptance layer — TapeOut's role |
| Who produced it, under which name? | TapeID Name |
| What does that agent say it does, and how do I reach it? | TapeID Card |
| What has it delivered before, under which criteria, with what evidence? | TapeID Record |
The two layers compose but do not overlap: TapeOut never needs to know who the author is, and TapeID never re-scores the circuit — it points at the acceptance result and makes the author's side of the story checkable.
The mapping
A taped-out circuit plus its task result is one piece of work with published acceptance criteria. The record format implemented in this repository's verifier (the ERC-8412 draft arithmetic: criteria, obligations, outcomes, decision rule) is designed to carry it field for field. It is not a claim that TapeOut uses ERC-8412 or that the two systems share a storage format:
| TapeOut artefact | Record field |
|---|---|
| Task id and its published scoring rule | taskRef and the decision rule |
| Netlist bytes of the taped-out circuit — the 0x00 / 0x01 / 0x02 record format, the signal order, the input packing | A GENERATED_ARTIFACT evidence item whose digest is taken over the exact bytes netlist(id) returns, so the format is part of the evidence definition |
A REF anywhere in the netlist sets mining weight to 0 | A REF-absence obligation with its own outcome |
| Area and depth terms of the cost rule (a latch counts six, depth is cubed) | One obligation per cost term, each with its own MET or UNMET outcome |
eval(id, inputs) outputs on the task's reference vectors | Evidence items whose digests the bundle commits to |
| Gate count, depth and cost result | The outcome of the cost obligations (MET or UNMET) |
| Pass or fail under the task rule | The verdict under the record's decision rule |
| A series of such results over time | A batch of records under one merkle root, anchored in a single zero-value transaction whose calldata is tag || root || count || anchoredAt (128 bytes) — the local verifier recomputes the root offline from the complete supplied record set |
In design Today this is a format plus a local verifier, not a pipeline. No TapeID record has been issued for any TapeOut work, and no record contract or anchor exists.
What the record must contain
A useful acceptance record has four parts. The criteria freeze the rule before the result is known. The evidence bundle binds the supplied bytes and execution results. The attestation reports each obligation separately instead of hiding a failure behind one score. An optional batch anchor commits to a collection of such records without making the anchor itself the evidence.
| Part | TapeOut-specific content | What a reader can check |
|---|---|---|
| Criteria | Task reference, test-vector reference, netlist and cost constraints, decision rule | The rule existed before the claimed outcome |
| Evidence | Netlist digest, circuit and processor identifiers, input/output vectors, gate and depth measurements | The submitted material is the material being judged |
| Attestation | Separate functional, REF-absence and cost outcomes, plus the verifier identity | Which condition passed or failed, and who reported it |
| Batch anchor | A merkle commitment to multiple record documents | The records still match the supplied anchor data |
A record should name the circuit owner separately from the TapeID name holder and from the verifier. A name proves neither circuit authorship nor honest verification; the evidence and the stated bindings are what make those relationships inspectable.
A worked example — synthetic
This is a design sketch for an imaginary task, not an official TapeOut task or an issued record. It shows why a single “passed” badge is insufficient: the functional result, netlist identity, REF policy and cost limits must remain separately visible.
taskRef: "tapeout.example.add4.v1" // synthetic; not a registry id
circuit: { processor: "0x…", id: "…", owner: "0x…" }
decisionRule: "ALL_REQUIRED"
obligations:
0 netlist digest matches netlist(id)
1 eval(id, input) matches every published vector
2 no REF record appears in the supplied netlist
3 (NAND + LATCH) + 6 × LATCH is within the stated area limit
4 longest combinational path is within the stated depth limit
evidence:
exact netlist bytes, circuit/processor identifiers,
input/output vectors, measurements and their source references
attestation:
one outcome per obligation, a bundle commitment,
the verifier identity and an explicit verdictWith ALL_REQUIRED, a circuit can compute correctly and still fail the record because a cost obligation is UNMET. Conversely, a good score does not establish who authored it or whether the evidence belongs to that circuit. The record must expose those distinctions rather than turn a mining score into a general reputation claim.
The verifier in this repository checks document consistency and decision-rule arithmetic; it does not currently execute a TapeOut circuit or fetch a TapeOut netlist. Connecting those reads and checks is the implementation work still ahead.
To exercise the existing format checks, run the local commands on the verification guide. The example above was never issued, anchored or submitted to TapeOut.
What is not claimed
- No integration: no TapeID component reads or writes TapeOut state.
- No deployment: no TapeID registry, gateway, record contract or anchor exists.
- No inherited history: no name, record or anchor from any earlier project counts as TapeID's.
- No endorsement: the mapping above is a design choice, not a partnership.