Preview mode · no live funds deployed

The market moves. BRICK builds.

BRICK is a fee-driven protocol that turns eligible trading activity into recurring on-chain masonry events — built layer by layer, with permissionless execution.

2% ETH-side fee · 0.5 ETH trigger threshold · permissionless execution

Structure
Masonry events recorded
Masonry eventSimulated
Event
Block
Time
Assigned
Preview event · not live
0.00 / 0.50 ETH to next eventPreview data
Drag to inspect

Structure preview unavailable on this device

Fig. 01 — structure, simulated
Permanent liquiditySimulated
No events yet
Masonry eventsSimulated
No events yet
BRICK sent to graveSimulated
No events yet
Execution thresholdConstant
0.5 ETH
Fixed constant · BRICK_THRESHOLD
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.

  1. 01
    An eligible swap pays the protocol fee Eligible swaps pay a 2% fee on the ETH side. The fee is routed to the hook. FEE_BPS = 200
  2. 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
  3. 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.0025 ETH 0.5% of the threshold BRICK_THRESHOLD = 0.5 ether
  4. 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, …)
01

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.

Credit is not transferable

The contract increments a counter against the triggering address. It cannot be moved, sold, or reassigned. It records who did the work.

Anyone can trigger it

There is no privileged keeper. Once the pot reaches the threshold, any address may call the function and receives a 0.5% execution reward — 0.0025 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.

02

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 ETH side of a trade in the protocol pool, collected as ETH by the hook. 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 0.5% 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.0025 ETH execution reward. The remaining balance is processed by the fixed allocation rules below.

Parameters
ParameterValue
Execution functionlayBrick()
Fee applies toExact-input swaps in both directions, and exact-output buys. Exact-output sells are not charged.
Fee can changeNo. FEE_BPS is a constant with no setter.
Threshold0.5 ETH
Caller reward0.0025 ETH (0.5% of the threshold)
ChainEthereum mainnet · Uniswap v4
Token contractPending deployment
Hook contractPending deployment
Where each pot goes — four constants, readable in the contract
35%
Protocol-owned liquidity
Added as full-range LP owned by the hook. The remove-liquidity path reverts for every address.
27%
Buyback & burn
Buys BRICK and sends it to a dead address. Circulating supply only decreases.
37.5%
Operations
Paid in ETH to a fixed address set at deployment. The team holds no tokens, so this is its only revenue.
0.5%
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

Accounting backing

Cumulative ETH credited to permanent liquidity, divided by circulating supply. Credited ETH only rises and supply only falls, so this figure cannot decrease.

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

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.
04

Contract

ItemState
DeploymentNot deployed. No addresses exist yet.
ChainEthereum mainnet · Uniswap v4
Supply1,000,000 BRICK, fixed at deployment
Test suite27 of 27 passing, including the mainnet-fork launch rehearsal against the canonical PoolManager
In-house reviewAdversarial review complete and published, including known open items
Third-party auditNot started. No audited language should be used until one is complete.
05

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?
38% of each pot is paid in ETH to a fixed operations address, of which 0.5% is the execution reward, leaving 37.5% net. The team receives no token allocation — the entire supply seeds liquidity — so this fee is its only revenue.
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.