TapeMine

Contract architecture

Each processor uses three contract types across five intended instances. TapeOut and Behemoth are deployed separately, with independent materials and income.

Three contract types, five intended instances per processor: a NAND and a LATCH receipt, one receipt distributor, and the pool contract deployed twice, as the Optimal Pool and the Regular Pool.

The source shown is TapeoutMinerPool/2.3.0: the accounting of the SALUS remediation, with one distributor serving both custody pools of a processor.

012 of 2 addresses configured

NAND entitlement receipt

ERC-1155 receipts for the NAND category. IDs 1…S are issued sequentially with a supply of exactly one each, and every ID is an equal share of the NAND income of its processor's custody pools.

TapeoutEntitlementReceipt.sol

022 of 2 addresses configured

LATCH entitlement receipt

ERC-1155 receipts for the LATCH category. Same code as the NAND receipt, deployed separately: LATCH #1 and NAND #1 are unrelated entitlements.

TapeoutEntitlementReceipt.sol

032 of 2 addresses configured

Receipt distributor

One per processor. Holds the NAND and LATCH receipts until each allocated wallet claims its own, for both custody pools: each receipt is allocated and delivered once and then earns in both pools. The allocation is recorded on-chain as ID ranges per wallet.

TapeoutReceiptDistributor.sol

044 of 4 addresses configured

Miner custody & BEM distribution pool

Holds miner NFTs, collects their BEM through Mining.claim, and distributes what it actually receives. Each processor deploys it twice, as the Optimal Pool and the Regular Pool; both pay the same NAND and LATCH receipts and bind the processor's one distributor.

TapeoutMinerPool.sol

One implementation, two receipt instances

The NAND and LATCH receipts are two separate deployments of the same source file, TapeoutEntitlementReceipt.sol. They differ only in constructor arguments (category, name, symbol, metadata URI and issuer). The contract has no immutables, so both deployments have identical runtime code, and the miner pool only binds to receipts whose code hash and category() match.

Two processors, separate deployments

TapeOut and Behemoth are separate processors. Each is intended to deploy its own receipts, distributor and Optimal and Regular Pools, bound to its own miner collection; nothing is shared between processors. Within a processor, both custody pools pay the same NAND and LATCH receipts, and each divides its own income by its own miners' materials. Pool Rules

One distributor for both pools

In TapeoutMinerPool/2.3.0, each processor's distributor is fixed at deployment to its Optimal Pool and its Regular Pool, which share one NAND and LATCH receipt pair. Receipts are allocated and delivered once; each pool binds the same distributor, once, and keeps its own income and claim history. The pools do not check each other's binding, so this site reads both directions once addresses are configured: the distributor's optimalPool() and regularPool() against the configured roles, and each pool's distributor() against the configured distributor. These are values the contracts report, not proof of genuine code.

How they connect

The NAND and LATCH receipts are deployed, issued in batches, corrected if necessary, and their issuance is finalized, which fixes each supply permanently.
The Optimal Pool and the Regular Pool are deployed with the same two receipt addresses, each with its A/B recipients and a fixed depositor whitelist. One distributor is then deployed for both, fixed as optimalPool() and regularPool().
The receipts are moved into the distributor, which records each wallet's allocation as ID ranges and is finalized. Finalization opens receipt claims, with no deadline; each receipt is allocated and delivered once.
Each pool's owner binds that same distributor, once, and activates the pool with the final receipt supplies. Activation requires both issuances and the allocation to be finalized.
Both receipts, the distributor and a pool renounce ownership; only then can that pool's first miner admission succeed, which opens its custody. The two pools do not wait for each other.
Anyone can harvest the miners' BEM; receipt holders claim per ID, and anyone can release a pool's A or B share, which also sends its sink share to 0x…dEaD.

Activation, open receipt claims and open custody are three different states. Receipt claims open at allocation finalization, before activation; custody opens only at the first successful admission. A finalized allocation does not mean every beneficiary has claimed.

Read the architecture specification ACCOUNTING.md

Build settings

Build settings from 8819a59
Compiler	Solidity 0.8.24
EVM version	paris
Optimizer	Enabled, 200 runs
Pipeline	via-IR
OpenZeppelin Contracts	5.4.0
Pool VERSION	TapeoutMinerPool/2.3.0
Source revision	8819a59

Build settings from 8819a59 · foundry.toml / package.json

Production code only

This page shows the production sources and the library and interfaces they use. The repository also contains test-only code that is never presented here as production:

Test only src/canary/RecoverableTapeoutMinerPool.sol

Recoverable canary copy of the pool for a bounded live test. It adds an owner-bound recovery controller, a single fixed depositor, a scope limited to two designated miners, irreversible shutdown and fixed-wallet NFT returns, so its code and permissions differ from production.

Test only src/canary/CanaryParticipant.sol

Helper contract acting as the canary test's second receipt holder.

Unit, fork and invariant test suites and their mocks under test/.

Addresses of test deployments are never configured here as production contracts. An instance without a configured address is shown as not configured; that describes this site's configuration, not a check of the chain.

A bounded mainnet canary built from these sources used the owner's own wallet and test assets and the earlier 100 : 1 : 1 split, so it does not validate the current one. Its recorded outcome is PARTIAL_AUTOMATION_FAILED_RECOVERY_AND_ACCOUNTING_PASS: part of the original automation failed, while recovery and accounting reconciled. A later local rehearsal does not change that record, and none of its addresses is configured on this site. AUDIT_REMEDIATION_REPORT.md (opens in a new tab)

PoolMath.sol IMining.sol IReceiptDistributor.sol Assessments, reviews and verification evidence

File integrity

Each file matches the git blob GitHub reports at 8819a59 (opens in a new tab). Reproduce with git show 8819a59:<path> | shasum -a 256.

File	Lines	SHA-256	Git blob
`src/TapeoutEntitlementReceipt.sol` (opens in a new tab)	157	`f5657c2827ca9650…`	`b317e3daae`
`src/TapeoutReceiptDistributor.sol` (opens in a new tab)	338	`b73840585f2e1e71…`	`357fa682d8`
`src/TapeoutMinerPool.sol` (opens in a new tab)	915	`5cb9e6bd8cca8409…`	`acf502971c`
`src/PoolMath.sol` (opens in a new tab)	120	`4b9b53b542d64243…`	`ad8192485a`
`src/interfaces/IMining.sol` (opens in a new tab)	53	`c8d8c41b57f55bc3…`	`491c93e657`
`src/interfaces/IReceiptDistributor.sol` (opens in a new tab)	17	`7e02dc0d828ab2a3…`	`732d5304fc`

TapeMine's contracts are built from the open-source tapeminecoop/groupmine (opens in a new tab) repository. Every file below is the repository content at commit 8819a59 (opens in a new tab), checked byte-for-byte against GitHub.