BRICK — every 0.5 ETH adds another layer to the structure

The build process

How the protocol builds

Eligible trading activity feeds the hook. Once the threshold is reached, anyone can trigger the next masonry event.

"Eligible" is exact, not vague. The fee is charged on exact-input swaps in both directions and on exact-output buys. Exact-output sells are left uncharged: taking the fee there would force it to be collected in BRICK, which breaks the rule that the pot is ETH. That is a deliberate gap, disclosed rather than papered over.

01
An eligible swap pays the protocol fee Eligible swaps pay a 2% fee on the WETH side. The fee is routed to the hook, and reaches operations and the caller as ETH. FEE_BPS = 200
02
The fee accumulates in the hook The ETH remains in the hook until the execution threshold is reached. The contract exposes no withdraw function to any address, including the deployer — the masonry path is the only route out. pot += fee
03
At 0.5 ETH, anyone can call layBrick() Once the hook balance reaches 0.5 ETH, any address may trigger the event. The caller receives the configured execution reward. Caller reward · 0.006 ETH 1.2% of the threshold BRICK_THRESHOLD = 0.5 ether
04
The event is recorded and the structure grows The execution will distribute the accumulated ETH according to the allocation rules and record the masonry event. Nothing is deployed yet, so no event has occurred. emit BrickLaid(idx, mason, …)

The Wall

One event, one brick

Each masonry event appends a record: block, the address that triggered it, the ETH assigned to liquidity, and the BRICK destroyed. The record is append-only.

Every brick carries its mason

The address that triggers an event is written into that brick permanently, and a soulbound counter increments against it — bricksLaidBy[]. It cannot be moved, sold or reassigned. Hover any stone above to light every brick that address laid.

Anyone can trigger it

There is no privileged keeper. Once the pot reaches the threshold, any address may call the function and receives a 1.2% execution reward — 0.006 ETH.

Masonry history renders here once deployed.

Build the wall

Every BRICK holder is represented in the monument. Your brick's area reflects your current BRICK balance relative to total supply. Split a balance across multiple wallets and the total represented area does not increase.

Connect your wallet to highlight your brick.

Simulated

Holder brick

Live, balance-proportional visual representation. Updates when you buy, sell, transfer, or split BRICK across wallets. Not permanent.

Masonry brick

Permanent monument growth. The monument grows by one structural brick when layBrick() is successfully triggered. It never shrinks.

Hover a brick Area is proportional to balance · live state, not permanent

Building a brick is a visual representation of your current balance. It does not mint an NFT, create a separate token, grant governance rights, or change the masonry accounting.

The Quarry

Mining is destruction

You mine by destroying BRICK. The tokens go to the grave and never come back, and in the same transaction circulating supply falls — which is the only input to the accounting ratio this protocol is built on. There is nothing to unstake.

Paid from fees, not emission

Each epoch's miners split 27% of one masonry pot, pro-rata to the BRICK they destroyed. That ETH was collected from real trades. No supply is minted to pay it, no schedule halves it, and no miner is paid out of another miner's loss.

You mine into the next brick

An epoch is paid by the brick after the one that closes it. The delay is the point: the pot is public and anyone can trigger masonry, so without it a large holder could burn at the last second and take a slice they knew the size of.

Cut the face

Every miner in the open epoch holds a slab of it, sized by the BRICK they destroyed. When the next brick is laid, that course settles and its ETH becomes claimable.

Preview

Rate — ETH per 1,000 BRICK destroyed

—awaiting deployment

Open epoch—

Destroyed this epoch—

Miners this epoch—

Settling next—

Slice per brick0.135 ETH

Payout ceiling3× value destroyed

Destroy BRICK

BRICK

Connect a wallet to see what a cut would earn.

Irreversible. Destroyed BRICK cannot be recovered by anyone, including the protocol, and the epoch's ETH is only claimable after the following brick is laid.

Settled — claimable

—ETH

Pull-based, and it never expires. An epoch you never got round to claiming is still claimable in full a year later — the contract has no sweep and no deadline.

Hover a slab Slab width is proportional to BRICK destroyed

If nobody mines

The 27% runs the original buy-and-burn: the protocol buys BRICK from the pool and sends it to the grave. An epoch with no miners behaves exactly as the protocol did before the quarry existed.

If an epoch is thin

Payout is capped at three times the pool-price value of the BRICK destroyed. Whatever the cap declines goes to the same buy-and-burn. Destroying one BRICK cannot capture a whole slice.

Epoch	Destroyed	Miners	Paid	Rate / 1k	Your claim
No epochs have settled. Mining begins when the pool does.

Mining does not mint a token, an NFT or a position. It does not grant governance rights, and it is not a yield product — the ETH an epoch pays depends entirely on how much the pool traded and how much BRICK other people destroyed alongside you. Destroying BRICK to mine can lose money.

Mechanics

The token

1,000,000 BRICK, minted once at deployment. No owner, no mint function, no blacklist, no pause, no upgrade path.

The fee

2% of the WETH side of a trade in the protocol pool, collected by the hook and paid out as ETH. Charged on exact-input swaps in both directions and on exact-output buys. A hook governs the single pool it is bound to, not the token — see below.

The threshold

At 0.5 ETH collected, any address can call layBrick() to trigger a masonry event and receives a 1.2% execution reward. Each event processes one threshold.

Eligible swaps pay a 2% fee on the ETH side. Fees accumulate inside the hook until the balance reaches 0.5 ETH. Any address can call layBrick() and receive a 0.006 ETH execution reward. The remaining balance is processed by the fixed allocation rules below.

Parameters

Parameter	Value
Execution function	`layBrick()`
Fee applies to	Exact-input swaps in both directions, and exact-output buys. Exact-output sells are not charged.
Fee can change	No. `FEE_BPS` is a constant with no setter.
Threshold	0.5 ETH
Caller reward	0.006 ETH (1.2% of the threshold)
Chain	Ethereum mainnet · Uniswap v4
Pair	WETH / BRICK — an ERC-20 leg, so explorers and aggregators index the pool correctly

Where each pot goes — four constants, readable in the contract

Nearly two thirds of every pot — 62.5% — is spent on the token itself: liquidity that cannot be removed, and supply destruction. The remainder funds operations, and the team holds zero supply.

Protocol-owned liquidity

Added as full-range LP owned by the hook. The remove-liquidity path reverts for every address.

The quarry

Paid to the miners who destroyed BRICK in the settling epoch. Whatever they do not take buys BRICK and sends it to a dead address instead. Either way circulating supply only decreases.

Operations

Paid in ETH to a fixed address set at deployment. The team holds no tokens, so this is its only revenue.

Execution reward

Paid to whoever calls layBrick(). Deducted from the operations share, so the four figures total 100%.

Allocation percentages describe the distribution of each 0.5 ETH pot at the moment a masonry event executes. They are fixed constants in the contract and total 100%.

Four different things, often confused

Implied liquidity price

Cumulative ETH credited to permanent liquidity, divided by circulating supply. Credited ETH only rises and supply only falls, so this figure cannot decrease. It is an accounting ratio, not a redemption right — no holder can exchange BRICK for that ETH, because it sits in a position nobody can remove. The contract calls it impliedLiquidityPriceWei() and not a floor, deliberately.

Active liquidity

What the position actually holds right now. The LP is full-range, so its composition shifts with price. It is not the same number as the one above.

Market price

What the pool will trade at. Set by supply and demand. Nothing in the contract sets, defends, or targets it.

Protocol guarantees

Two, both enforced in code: liquidity added by the hook cannot be removed by any address, and burned supply cannot return. Everything else is a consequence, not a promise.

Design notes

How BRICK is designed to operate

Token

Fixed-supply token

1,000,000 BRICK was minted once. The token has no owner, mint function, blacklist, pause function, or upgrade path.

The supply is fixed at deployment and no further BRICK can ever be created. Because the token holds no privileged functions, every mechanic that matters lives in the Uniswap v4 hook, where it is readable as constants rather than as permissions.

Fee

2% ETH-side fee

A 2% fee on defined ETH/BRICK swap types builds the masonry pot.

The hook charges 2% on the ETH side of exact-input swaps in both directions and on exact-output buys. Exact-output sells are not charged. Fees accumulate as ETH until the pot reaches 0.5 ETH.

Masonry event

Any address can call layBrick()

Once the threshold is reached, any address can call layBrick(). Each event processes one threshold.

Execution is permissionless and the pot is readable before a transaction confirms, so the timing and size of each event can be anticipated and traded against. Capping every event at one threshold bounds how much any single instance is worth acting on. A price bound was tested and removed: on full-range liquidity a bound tight enough to matter also prevented the event completing. Publish the final keeper and execution policy before launch.

Guarantees

Two protocol rules enforced in code

Liquidity added by the hook cannot be removed, and burned BRICK cannot return to circulation.

These two rules hold regardless of market conditions, and the removal path reverts for every address including the deployer. Everything else is a consequence rather than a guarantee. Outside liquidity providers cannot add to or rebalance the managed position, and founding liquidity cannot be withdrawn by anyone, including whoever provided it.

Metric

Accounting floor

The accounting floor is a transparent on-chain metric: cumulative ETH credited to permanent liquidity divided by circulating supply.

It is not a redemption price, a market-price guarantee, or a promise of value. Credited ETH only rises and circulating supply only falls, so the figure cannot decrease — but the liquidity is full-range, so what the position holds at any moment varies with price. brickStats() returns every input, so the figure can be recalculated independently.

Review status

Pre-launch review is underway. Source, tests, parameters, and review notes will be published before deployment.

27 of 27 tests pass, including a launch rehearsal against the canonical PoolManager on a fork of Ethereum mainnet. The adversarial in-house review is complete and published in full, including the items that remain open. No independent third-party audit has been completed, and audited language should not be used until an external review is finished.

Item	State
Deployment	Not deployed. No token, pool, bricks or on-chain history exist yet.
Token address	Does not exist yet
Hook address	Does not exist yet
Pair	WETH / BRICK
Chain	Ethereum mainnet · Uniswap v4
Pair	WETH / BRICK — an ERC-20 leg, so explorers and aggregators index the pool correctly
Supply	1,000,000 BRICK, fixed at deployment
Test suite	27 of 27 passing, including the mainnet-fork launch rehearsal against the canonical PoolManager
In-house review	Adversarial review complete and published, including known open items
Third-party audit	Not started. No audited language should be used until one is complete.

Questions

Does every BRICK trade pay the fee?

No, and it is worth being exact about this. In Uniswap v4 a pool is identified by its two tokens, its fee tier, its tick spacing and its hook. The hook governs the one pool it is bound to — not the token. Any address can create a second BRICK/ETH pool with no hook attached, and trades routed through that pool pay nothing to the protocol. This is not hypothetical: one recent v4 launch has 242 pools, of which 233 carry no hook. What protects fee capture in practice is depth, not permission — routers send orders to the pool with the best price, and the protocol pool's liquidity is permanent and grows with every masonry event, while a rival pool would need someone to fund and maintain it at a loss. The claim this site makes is therefore "trades in the protocol pool pay 2%", and nothing stronger.

Can the liquidity be removed?

No. It is held by the hook contract and the remove-liquidity path reverts for every caller, including the deployer and the hook itself. There is no emergency withdraw function. This is verified against the real PoolManager on a mainnet fork.

How does the team make money?

62.5% of every pot is spent on the token — 35% into liquidity that cannot be removed, 27% on destroying supply: paid to the miners who burned BRICK in the settling epoch, or spent buying BRICK and sending it to a dead address when no one mined. The remaining 36.8% is paid in ETH to a fixed operations address, after the 1.2% execution reward is carved out for whoever triggered the event. That fee is the team's only revenue: there is no token allocation, no vesting schedule and no unlock, because the entire supply seeds the pool at deployment. A team holding none of the supply and taking a disclosed, fixed share of fees cannot quietly sell into you — which is the failure mode a token allocation exists to enable.

Is mining a way to make money?

It is a way to lose money as easily as make it, and the mechanism is honest about which. You destroy BRICK, permanently, in exchange for a pro-rata share of 27% of one masonry pot — 0.135 ETH at a full pot. Whether that trade is profitable depends on two things you cannot know when you commit: how much BRICK everyone else destroys into the same epoch, and whether the pool trades enough to fill the next pot at all. If a hundred people crowd one epoch, each of them gets a hundredth of the same slice. The payout is also capped at three times the pool-price value of what you destroyed, so there is a ceiling on the upside and no floor under the downside beyond the tokens you chose to burn. What the protocol guarantees is narrow and worth stating exactly: the ETH is real, it came from trades that already happened rather than from newly minted supply, the split is a constant nobody can change, and the claim never expires. It does not guarantee that mining pays.

Why proof-of-burn instead of a round-based game?

Because the wager version pays winners out of losers, and this protocol's only claim is that its accounting ratio rises by construction. Proof-of-burn is that claim made callable: the BRICK goes to the grave, circulating supply falls, and the ratio rises in the same transaction. There is also no randomness to relay — a round-based game needs a beacon or a VRF to be live or the protocol stops turning, and this one needs nothing but the pool.

What happens to the 27% if nobody mines?

It buys BRICK from the pool and sends it to a dead address, exactly as the protocol did before the quarry existed. The same applies to any part of the slice the payout ceiling declines. This is deliberate: the worst case for the mining layer is the behaviour of the version without it, so adding it cannot leave holders worse off.

Is there a team allocation or unlock?

No. The full 1,000,000 supply is minted once and seeded into the pool. There is no vesting schedule, no treasury wallet, and no mint function.

What does the backing figure actually mean?

Cumulative ETH credited to permanent liquidity divided by circulating supply. It cannot decrease. It is not redeemable and it does not set market price — see the four definitions under Mechanics.

Who can trigger a masonry event?

Any address, once the pot reaches 0.5 ETH. The caller receives a 0.5% execution reward. There is no allowlist and no privileged keeper.

Where are the full limitations written down?

Under Design notes — every plate expands to the technical detail, including what is still open. The complete in-house review, with findings that have not been resolved, is published alongside the source before deployment.

What if the operations address stops working?

Nothing halts. The payout is attempted without reverting, so a failed transfer cannot block masonry events. The failure is recorded as an event.

The market moves. BRICK builds.