WelfyBack. Forth. Only grows.
On X The loom

$WELFY · Robinhood Chain (4663) · Uniswap v4

The law

Fifteen articles. Everything the loom does, and everything it cannot do. Every number below is fixed when the contracts are deployed: there is no owner, no admin, no setter, no upgrade path and no pause, so nothing here can be changed afterwards by anyone, including us.

Article 01What this is

A loom whose state lives in a Uniswap v4 hook on Robinhood Chain. Every swap on the pool passes the shuttle once and lays one row of cloth. Every swap pays the same toll into a reserve. When the rows fill the length of the piece, the piece is cut off the loom in that same transaction: the whole reserve buys $WELFY on the pool and sends it to the dead address, the piece is sealed, and the loom starts a new piece empty.

There is no outside income. Everything that is burned came from the tolls of the people who traded. Nothing is paid to anyone, at any time, in any form.

Article 02The warp, the row, the piece

  • The warp is a fixed number of threads, set at deployment. It is the width of every piece for the life of the contract. The cloth grows along its length, never across its width.
  • A row is one pass of the shuttle: exactly one row per swap, no exception. There is no swap that does not weave, and no way to weave without swapping.
  • A piece is the cloth woven between two cuts. Its length is a fixed number of units of thickness, set at deployment, and it is the only thing that decides when the cut happens. A piece is therefore not a fixed number of rows: many fine rows and few thick ones can fill the same length.

Article 03The shade

A buy lays a light row. A sell lays a dark row. The direction is read from the swap itself, inside the hook; no oracle and no address are involved.

The shade is a record, not a score. It enters no arithmetic anywhere. The toll, the advance, the clamp, the tone and the cut are identical for the two values, and no rule reads the shade for anything other than storing it and drawing it. A design in which one direction were worth more than the other would be a machine that pays people to push a price, and that is not what this is.

Article 04The thickness

A row's thickness comes from the size of the swap, through a scale that is monotone, concave, integer and clamped. Monotone: a larger swap never advances the piece less than a smaller one. Concave: many small trades weave more cloth than one trade of the same total size.

Concavity is a requirement, not a taste. It is what stops a single very large trade from finishing a piece on its own, and what makes the cloth record how volume arrived rather than only how much of it there was.

The stored thickness is quantised, and the quantised value is the one that counts: it is what is drawn and what is added to the length. Otherwise the cloth on screen and the counter beside it would disagree by a rounding error that grows all piece. Quantisation rounds down.

Article 05The advance scale

Published as the exact integer formula, not as a description of one, before anything is deployed. The candidate, pending the calibration of article 15:

advance(size) = min( clamp , quantise( isqrt( size / unit ) ) )

where isqrt is the integer square root, unit is a fixed scale chosen so that an ordinary trade on the pool lands in the middle of the quantised range rather than at either end, and quantise rounds down. There is no division by a variable and no floating point anywhere in the path.

Article 06The clamp

No single row may be thicker than a fixed fraction of a piece. A swap large enough to exceed it lays a row at the clamp, and the excess is lost, not carried into the next piece. Carrying it would let one swap cut two pieces, and the simpler rule is the one that can be said in a sentence.

The clamp has a consequence worth stating plainly: no piece can be woven in fewer than length / clamp swaps, whatever their size. A single trade cannot cut a piece, and neither can two.

Article 07The session table

A row woven while the market underneath the Stock Tokens is shut is laid in a night tone. The test is arithmetic on the block's own timestamp against a table of weekdays and hours fixed at deployment and printed here in full at launch. No oracle, no external call, nothing in the path every trade takes that can fail.

What the table does not know: market holidays, which weave as open days; early closes, which weave as full days; and unscheduled halts, which nothing on chain can see.

This is acceptable for one reason and it is stated rather than buried: the tone touches no flow. It changes no toll, no advance, no cut and no burn. It is a shade of thread in a picture. An oracle would fix a cosmetic error by adding a dependency and a failure mode to the hot path, which is the wrong trade.

Article 08The toll

A fixed share of the size of every swap, in the quote asset, taken in the hook and added to the reserve.

  • The same rate in both directions.
  • The same rate at every row and at every position in the piece.
  • The same rate for every address.
  • The same rate at every moment: no setter, no schedule, no decay, no discount, for anyone.

The toll rounds up, the advance and the quantisation round down, and the difference stays in the reserve, which is to say it is eventually burned. Rounding is treated as a security property and proven symmetrically on both directions before deployment.

Article 09The reserve

One way in, the tolls. One way out, the dead address, at a cut. No owner, no withdrawal function, no settable destination, no pause.

The reserve is the hook's own balance of the quote asset, not a stored counter: a counter and a balance can disagree, and the figure the page shows has to be the one the cut spends. It is public and live, shown beside the distance still to weave, so that the size of the next burn and the distance to it are both known before it happens. There is no snapshot, no announcement and no discretion about timing.

Article 10The cut

When the rows fill the length, in the same transaction, in this order:

  • The row that crossed the line is written first. The piece that cuts is the piece that includes it.
  • The whole reserve buys $WELFY on the pool.
  • The $WELFY bought goes to the dead address.
  • The piece is sealed with its number, its first and last block and its row count, and enters the catalogue.
  • The loom resets: length woven to zero, piece number plus one, warp unchanged.
  • Nobody receives anything. No rebate, no share, no mark, no mention.

The buy is the only step that can fail, and the contract is built so that a cut can never revert the swap that triggered it: on failure the piece still seals, the loom still resets, and the burn is retried on the next swap. A full loom can never brick the pool and a failed buy can never trap the reserve.

The swap that finishes a piece pays the same toll as every other swap in it and receives nothing extra. It is not a prize, so it is not a race, so there is nothing for a sequencer to sell.

Article 11Fixed at deployment

Each of these is written into immutable storage with no setter, and each is printed here with its exact value at launch.

The warp width
set at deploy
The length of a piece
set at deploy
The advance scale and its unit
set at deploy
The quantisation of a thickness
set at deploy
The clamp on one row
set at deploy
The toll rate
set at deploy
The session table
set at deploy
The quote asset of the pool
set at deploy

There is no function that changes any of them, no admin key, no timelock holding a key that could, and no proxy in front of any contract. Liquidity owned by the protocol sits in a locker with no withdraw function, and third-party liquidity is refused by the hook, because the cut buys on this pool and an outside position would be on the other side of the burn.

Article 12Supply and issuance

A fixed supply, minted once by the token's constructor. No mint function afterwards, no owner, no blacklist, no pause, nothing that can freeze or seize a balance. The dead address is a normal holder and the burn is a transfer to it, readable by anyone on the explorer.

The full split is published here before launch, alongside the contract addresses. The team keeps nothing from the flow of the mechanism: the reserve has one destination and it is not us.

Article 13What a holder has

Exposure to a supply that only goes down, at a rate the loom publishes before it happens.

Nothing else. No claim on the reserve, no share of anything, no right over the loom or the catalogue, no governance, no vote, no access. This article says no more than that because there is no more than that, and any page, post or person saying otherwise is not speaking for this contract.

Article 14What can go wrong

  • A frozen loom. In a dead market the piece sits half-woven and the reserve sits full, possibly for a long time. There is no decay, no timer and no lever in the contract to do anything about it. This is the honest failure state and the front page shows the reserve and the distance rather than only the total burned, so that it is legible the moment it starts.
  • Somebody fills a piece on purpose. At the cost of the tolls and the price impact of a one-sided run, floored by the clamp at length / clamp trades. What they get is a burn that belongs to everybody.
  • The session table is wrong on a holiday. Cosmetic, touching no flow. Article 07.
  • A calibration that cannot be fixed. Nothing has a setter, so a length badly chosen against the clamp stays badly chosen. This is why the parameters are simulated on real traces before a line is deployed, and why the clamp is derived from the floor on trades rather than picked as a fraction.
  • The word burn carrying more than it should. A burn reduces supply. What that does to a price depends on demand, which this protocol has no opinion about and no lever on. No page of this site says otherwise.

Article 15Open questions

  • The length of a piece and the toll rate are one question, not two. The length sets how long a piece takes, the rate sets how much the reserve holds when it gets there, and the product is the only number anyone will look at. Publishing one without the other would be publishing nothing. Both are simulated on real traces from the chain's deepest pools before deployment.
  • The shape of the advance scale. The integer square root is the candidate. Whatever wins the simulation is published as the exact formula of article 05.
  • Whether the catalogue should render on chain. The events and the packed rows already make every piece reconstructible by anyone. An on-chain renderer would remove this site from the path at a real cost, and it changes no rule, so it is a later addition rather than a launch requirement.
  • The quote asset. The one open question that changes what has to be cleared before launch. A Stock Token would tie the project to the chain's own asset class and moves the legal work from light to heavy; it is decided before the contracts are written, not during.

No contract is deployed. Nothing on this site is an offer of anything, and the contract address will be published here and on X at launch, nowhere else.