Smart contracts

Contract source code

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 00e37c7(opens in a new tab), checked byte-for-byte against GitHub.

Not independently auditedNot yet deployedSource at 00e37c7 · 2026-10-21Internal reviews and verification evidence

The contracts of one processor

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.

01Not yet deployed

NAND entitlement receipt

TapeoutEntitlementReceipt.sol

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.

View source

02Not yet deployed

LATCH entitlement receipt

TapeoutEntitlementReceipt.sol

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

View source

03Not yet deployed

Receipt distributor

TapeoutReceiptDistributor.sol

Holds the NAND and LATCH receipts until each allocated wallet claims its own. The allocation is recorded on-chain as ID ranges per wallet.

View source

04Not yet deployed

Miner custody & BEM distribution pool

TapeoutMinerPool.sol

Holds miner NFTs, collects their BEM through Mining.claim, and distributes what it actually receives. Each processor is intended to deploy it twice, as the Optimal Pool and the Regular Pool, both paying the same NAND and LATCH receipts.

View source

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

How they fit together

1.The NAND and LATCH receipts are deployed, issued in batches, moved into the distributor, and their issuance is finalized.
2.Two custody pools, the Optimal Pool and the Regular Pool, are deployed from the same pool code with the same two receipt addresses, their A/B recipients and a fixed depositor whitelist, then each is activated with the final receipt supplies.
3.The distributor records each wallet's allocation as ID ranges and is finalized. Each wallet then claims its own receipts, with no deadline.
4.Whitelisted depositors admit miners built for optimal seats into the Optimal Pool and the regular miners into the Regular Pool. Anyone can harvest their BEM; receipt holders claim per ID from each pool, and anyone can release a pool's A or B share, which also sends its sink share to 0x…dEaD.

Full details: ARCHITECTURE.md(opens in a new tab) and ACCOUNTING.md(opens in a new tab) at the same commit.

Build settings

Build settings from 00e37c7 · foundry.toml / package.json

Compiler: Solidity 0.8.24
EVM version: paris
Optimizer: Enabled, 200 runs
Pipeline: via-IR
OpenZeppelin Contracts: 5.4.0

Production code only

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

Test onlysrc/canary/RecoverableTapeoutMinerPool.sol(opens in a new tab)
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 onlysrc/canary/CanaryParticipant.sol(opens in a new tab)
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. Every instance is listed as not yet deployed until its production address is configured.

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)

File integrity

Each file matches the git blob GitHub reports at 00e37c7(opens in a new tab). Reproduce with git show 00e37c7:<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)	300	67f0b24fa54783b1…	b6bae3c4f1
src/TapeoutMinerPool.sol(opens in a new tab)	791	6a2d0c34b42ff97c…	3cfd9b093d
src/PoolMath.sol(opens in a new tab)	77	c7ab82e43c2a2d0b…	6adf9f497e
src/interfaces/IMining.sol(opens in a new tab)	53	c8d8c41b57f55bc3…	491c93e657