Does every BRICK trade pay the fee?
No. 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 loses money as easily as it makes it. You destroy BRICK, permanently, in exchange for a pro-rata share of 27% of one masonry pot, 0.0405 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, and that price is read when the epoch settles, not when you burned, so a fall in the meantime shrinks the ceiling with it. There is a ceiling on the upside and no floor under the downside beyond the tokens you chose to burn. The guarantee is narrow: 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.
What is the worst case for a miner?
You destroy BRICK and receive nothing, permanently. An epoch is funded by the brick laid after the one that closes it, and each brick requires the pot to reach 0.15 ETH, roughly 7.5 ETH of trading through the protocol pool at the 2% fee. If trading dries up before that happens, the epoch is never funded: there is no expiry that refunds you, no treasury that makes you whole, and no function that returns burned supply, because the burn is what makes the mechanism work in the first place. The claim itself never expires, so an epoch funded a year late still pays in full. But nothing guarantees it is ever funded. Mine on the assumption that the tokens are gone and the ETH is a maybe, because structurally that is exactly what it is.
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 implied liquidity price 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.15 ETH. There is no allowlist and no privileged caller: the function is open, and whoever calls it receives a 1.2% execution reward of 0.0018 ETH at a full pot. Open is not the same as reliably profitable. The call costs about 465,000 gas, so the reward covers it up to roughly 3.9 gwei; above that, calling it loses money and there is no reason to expect a stranger to. The team therefore runs a keeper as a backstop, which earns the operations share regardless and can afford to lay a brick at a loss when gas spikes. The trigger is permissionless. The expectation that the open market always carries it is not something this protocol relies on.
Where are the full limitations written down?
Under
Limitations. Every plate expands to the technical detail, including what is still open. The complete in-house review, with the findings that remain unresolved, is published alongside the source at deployment, not before. Until then this page is self-attested, and worth reading as such.
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.
