The price does not move itself
It can work out exactly where a price should be. Instantly, for free, a thousand times before the next block. It cannot move it there. Moving a price is not a conclusion — it is capital put at risk across a spread, in public, where being wrong costs money. No amount of thinking substitutes for it.
So the agent hires. What it is buying is legwork.
Nothing is deployed. No mainnet address, no testnet address, no audit, no liquidity. The contracts are written and tested; that is all. Every number on this site is illustrative and every address field is empty on purpose.
Thinking is free now. Carrying still costs.
An AI agent can read every book at once, price an asset in a millisecond, draft the trade, sign it and change its mind before the block closes. There is no scarcity left in any of that.
There is one thing it cannot do, and it is the only thing a market actually records. It cannot move a price.
An agent that has worked out exactly where the price ought to be is in precisely the position of an agent that has worked out exactly which apartment to rent: correct, certain, and unable to do the one remaining thing that matters, which is to physically go there.
So it hires somebody who is going that way. The old word for the part of a job that has to be done with your feet is legwork, and it is the only part of this one that is scarce.
AI agents can think, research, code, trade, make payments. But ask one to pick up a package, inspect a property, or physically show up somewhere and they hit a wall. Agents have brains. We're giving them hands.
One writes the record, one holds the money, one prints the receipt.
Does nothing to your swap. No fee, no delta, no rejection, no price impact. The price quoted is the price you get, and the measured cost is 28,411 gas more than an identical pool without it.
What it does is keep a record. On every swap that moves the tick it writes one leg: where the price was, where it ended up, who carried it, and when. Append-only. Nothing can rewrite or remove one.
Anyone posts a job: get the price across tick T and leave it there. The poster escrows ACTION.
Nobody accepts an errand. There is no register, no queue, no assignment. It is complete when some leg took the price past the target and the price is still past it 300 blocks later — whoever carried it and whatever they were doing.
An ERC-721 minted to the runner on every completed errand, drawn entirely on-chain as SVG. It records the leg, the tick crossed, the distance carried and what the job paid.
A receipt, not a permission. Nothing reads it, nothing is gated on holding one, and the mint is wrapped in a try so it can never hold up a payment.
An earlier version of this contract paid for a tick crossing. A crossing is an event, and events can be manufactured.
What a crossing bounty actually buys
Borrow, push the price down, push it straight back up, all in the same transaction. The legs in between satisfy every errand in the band — in both directions at once — and the price ends exactly where it started. The whole round trip costs twice the pool fee on a notional you keep. It is not a price move. It is a receipt for one.
1,950 of 3,000 posted tokens, drained in one transaction. That is the attack written as a test, run against the old design.
What this board buys instead
An errand is not completed by arriving. It is completed by arriving and still being there 300 blocks later — about an hour. That is the difference between paying for a state and paying for an event, and it is the only version of this idea that cannot be faked inside a transaction: to hold a price for an hour you have to carry real inventory for an hour, in public, where being wrong costs money.
The same attack now pays zero. Tick 167,067 → 167,055, both crossings recorded, nothing earned.
The twelve ticks between 167,067 and 167,055 are the round trip's only real cost: it paid the pool fee twice. The crossings still happened — that was never the problem. What no longer happens is getting paid for them. and watch it earn nothing.
You can be paid for work you didn’t know you were doing.
A trader buys because they wanted to buy, takes the price across the tick on the way through, holds their position because they meant to hold it, and the money is theirs whether or not they have ever heard of the contract. That is the design, not a side effect.
The honest answer is nothing, and that is measurable.
Both callbacks run after the thing they observe, so neither can refuse anything. There is no beforeSwap and no returned delta, so the trade is untouched. There is no beforeInitialize, so the Uniswap app can open the pool. There are no liquidity gates, so a provider can always leave.
A draft of this skimmed a few percent off every bounty for the liquidity providers. It was deleted, and the reason is worth the space.
claim may be called by anyone at any moment, so the caller chooses the instant the donation lands. A bot that mints a tight-range position, calls the claim, and burns it again takes the whole tip having provided liquidity for exactly one block.
A payment whose recipient is chosen by whoever calls the function is not a payment to liquidity providers. It is a bounty on calling the function.
So the board does not tip the pool. It sends it business: the trade that carries the price pays the ordinary swap fee like any other trade, to whoever was actually there to fill it — which is the only payment that can't be gamed by timing, because it is settled by the pool at the moment of the trade.
The runner receives the whole bounty. There is no skim anywhere in this system.
Everything fixed at deployment, and nothing after it.
The honest costs of all of this are listed in full under . They are not softened anywhere on this site.
Open jobs, the pay climbing on each of them, and a road the price has to be carried along. Drag the price across a target, then advance the block counter: the errand only completes if the price is still past the target 300 blocks later.
Illustrative — nothing is deployed. These errands, ticks, blocks and amounts are made up for this page. There is no chain behind it. The arithmetic and the rules, however, are the contract's: same formula, same integer truncation, same crossing predicate, same 300-block hold, same two claim routes.
One press is one swap, and one swap is one leg.
Uncheck it and claimLive refuses: a tick parked where nobody is providing is a number, not a price.
| # | Job | Target | Dir | Pay now | Rate / block | Escrow cap | Expiry | Status |
|---|
Four values, and they always add up: open = posted − paid − returned. No fifth line, because nothing else is ever taken out.
| leg | pre | post | runner | block |
|---|
Legs 0 and 1 were carried before any of these errands were posted. Each errand stores fromLeg — the leg count at the moment it was written — and anything earlier is somebody else's history, which is what stops the record being mined for work nobody asked for.
Drawn here exactly as Waybill._svg draws them on chain: same geometry, same palette, same strings.
Each press of Carry is one swap. Dispatch.afterSwap reads the pool's tick afterwards, compares it to where the last leg left it, and if it moved, writes one word. A swap too small to shift the tick writes nothing at all — there is no leg from a tick to itself.
Crossing a target does not pay. It starts a clock. Advance 300 blocks with the price still on the far side and the job is done; bring the price back before then and the crossing was worth nothing, which is the entire point.
Nobody on this board accepted anything, and the claim is a separate transaction that anyone may send. It always pays the runner in the record, so pressing claim yourself earns you nothing except the gas bill.
The pay is fixed by the block of the crossing leg, not the block somebody got round to claiming — advance the counter after a job is carried and watch its figure stay put. Whatever the poster escrowed above what the job paid goes straight back to the poster in the same transaction.
Eight moving parts, in the order they happen. Nothing here is optional and nothing here is administered.
On every swap that moves the tick, the hook writes down four things and nothing else: where the price was, where it ended up, who carried it, and when. That is one 256-bit word — which is the only reason it can afford to write one every time. Two words would double the cost of trading here for a record almost nobody reads at the moment it is written.
The hook does not know what an errand is, never holds a bounty, and cannot pay anybody. It runs after the swap, returns a zero delta, and has no bit set that would let the pool use that delta for anything.
legs.push(Legs.pack(pre, post, tx.origin, uint48(block.number)));
The poster names a target tick, what the job pays immediately, how fast that rises, the ceiling they are committing, and the block after which they may begin taking back whatever is left. The escrow moves out of their wallet at that moment.
The direction is not the poster's to choose. It is read from where the price actually is when they post: up = target > currentTick. An errand therefore always names somewhere the price is not, and posting a target equal to the current tick reverts. There is no such thing here as paying for a journey of zero length, and none for a job that can never pay anything: a post with base and rate both zero reverts too.
The errand also records fromLeg, the number of legs already written. Everything earlier belongs to somebody else.
An errand nobody wants is an errand that is not paying enough yet. The only honest answer to that is to wait, and let it pay more.
pay = min(escrow, base + rate × (legBlock − postedAt))
Note which block is in that expression. It is the block of the leg that carried the price across — not the block somebody got round to claiming it, and not the block the hold finished. Sitting on a completed errand earns nothing, so nobody has to watch.
Not somebody who applied. Any leg that took the price past the target counts, whoever wrote it and whatever they were doing. Usually the runner is not looking: they bought because they wanted to buy.
The test is half-open, and deliberately so.
A target sitting exactly where the leg started has been reached already — the previous leg left the price there — so it is not this leg's work. A target sitting exactly where the leg ended has been arrived at, and arriving counts.
This is the step the first version of the contract did not have, and the reason it was broken.
A crossing is an event. Events can be manufactured inside a single transaction: borrow, push the price down, push it straight back up, and the legs in between satisfy every errand in the band — in both directions at once — while the price ends where it began. Written as a test against the old design, that transaction took 1,950 of 3,000 posted tokens, and its only cost was the pool fee paid twice on a notional the attacker kept.
A state is not manufacturable that way. So the errand is completed by arriving and still being past the target HOLD = 300 blocks later, about an hour. To hold a price for an hour you have to carry real inventory for an hour, in public, where being wrong costs money — which was the claim the whole project rests on. Run against the fixed contract, the same attack pays nothing: tick 167,067 to 167,055, both crossings recorded, zero earned.
claim(id, legIndex, proofIndex)
Prove it held with a later leg: one at least 300 blocks after the crossing whose own end is still past the target. It is a fact about the past, so it never stops being true — this route cannot be raced, front-run, or lost to a later price move, and it is still claimable years afterwards.
claimLive(id, legIndex)
Prove it with the pool's price right now: at least 300 blocks on, still past the target, and with liquidity actually in range. Cheaper, and available the moment it is true — but it reads a price that can move, and if the price comes back before anyone calls it, only a proof leg will do.
The liquidity check belongs to the live route because a tick parked where nobody is providing is a number, not a price: in an empty region it can be walked anywhere for the cost of gas alone. And note what is not checked — neither route inspects the whole interval. They compare two moments: the crossing, and a point at least 300 blocks later. A price that dips back and returns still qualifies. What cannot happen is the round trip inside one transaction, because no transaction spans 300 blocks.
Both routes are open to everybody and always pay whoever the record says carried the price. So the person who notices and the person who did the work do not have to be the same person, and racing to claim somebody else's errand earns you exactly nothing.
This is what lets a runner never hear about the board — and it is load-bearing in the withdrawal rules below, where somebody has to be watching and it had better not have to be the runner.
In one transaction: the runner is paid the whole bounty, and every token the poster committed above what the job actually paid goes back to the poster. There is no third share. Nothing is retained by the board, and no address in it is privileged.
The waybill is minted to the runner in the same call, inside a try. If the receipt contract were never bound, or ever stopped accepting mints, the runner is still paid and the board emits ReceiptFailed. Wiring a cosmetic NFT into the payment path would let one forgotten deployment transaction brick every claim the board will ever see.
Once an errand is posted the escrow is committed until the expiry the poster chose in advance — at least 600 blocks out, because the contract will not accept a shorter one. There is no function that takes it back early. Not for the poster, not for anybody. A cancel button is a button for pulling the money in the same block as the transaction that earns it, and a board where that is possible is a board where no sensible person works on credit.
After the expiry, taking it back is two transactions: announce(id), which is public and on chain, and then withdraw(id) no sooner than GRACE = 7,200 blocks — about a day — later.
The reason is that the contract cannot cheaply prove nobody completed the job. So rather than guess, it makes the poster say out loud, a day in advance, that they are about to take the money back — which is time enough for anyone holding a completing leg to claim it.
The honest limit. If literally nobody is watching during that day, a poster can still reclaim an escrow somebody earned. The claim is permissionless precisely so that the watcher does not have to be the runner — but the contract cannot make anybody watch.
Against the source as written: Dispatch.sol, Errands.sol, Waybill.sol, ActionLayer.sol, libs/Legs.sol. Nothing is deployed, so there is nothing to verify against a chain yet.
A leg is one stretch of the journey, packed into exactly one 256-bit storage slot.
pre | (post << 24) | (runner << 48) | (block << 208)
pre = int24(uint24( leg & 0xFFFFFF ))
post = int24(uint24((leg >> 24) & 0xFFFFFF ))
runner = address(uint160((leg >> 48) & (1<<160)-1))
block = uint48((leg >> 208) & (1<<48)-1)48 bits of block number runs out around block 2.8 × 1014. At twelve seconds a block that is roughly a hundred million years, which is long enough.
The hook keeps no history of its own beyond this array. It stores lastTick, the tick the previous leg ended on, and that is exactly where the next one starts: minting, burning and donating never move the tick, so the pool is its own record of where it was.
A v4 hook's permissions are its address: the PoolManager reads the low 14 bits to decide which callbacks to fire. Dispatch's constructor refuses to exist anywhere else — if (uint160(address(this)) & 0x3FFF != 0x1040) revert BadFlags();
| Bit | Mask | Callback | State | Why |
|---|---|---|---|---|
| 13 | 0x2000 | beforeInitialize | clear | So the Uniswap app can open the pool without the hook having a say. |
| 12 | 0x1000 | afterInitialize | set | Seeds lastTick, so the first leg — usually the largest the pool ever sees — is attributable. Returns its selector for every pool, bound or not, so it cannot refuse anything. |
| 11 | 0x0800 | beforeAddLiquidity | clear | No gate on providing. |
| 10 | 0x0400 | afterAddLiquidity | clear | Nothing to observe: liquidity does not move the tick. |
| 9 | 0x0200 | beforeRemoveLiquidity | clear | A provider can always leave. This is the bit that locks people in, and it is clear. |
| 8 | 0x0100 | afterRemoveLiquidity | clear | As above. |
| 7 | 0x0080 | beforeSwap | clear | The hook never sees a swap before it happens, so it cannot price it, block it or front it. |
| 6 | 0x0040 | afterSwap | set | The whole machine. Reads the tick, writes one leg, returns zero. |
| 5 | 0x0020 | beforeDonate | clear | Nothing here donates to the pool. See the risks section for why the tip was removed. |
| 4 | 0x0010 | afterDonate | clear | As above. |
| 3 | 0x0008 | beforeSwapReturnsDelta | clear | No delta can be taken before the swap. |
| 2 | 0x0004 | afterSwapReturnsDelta | clear | afterSwap returns an int128 because the signature demands one. With this bit clear, v4 ignores the value entirely. |
| 1 | 0x0002 | afterAddLiquidityReturnsDelta | clear | No charge on providing. |
| 0 | 0x0001 | afterRemoveLiquidityReturnsDelta | clear | No charge on leaving. |
Every bit that is set must be implemented and every bit that is clear must not be needed: a set bit with no function behind it is a callback the PoolManager makes into nothing. Dispatch declares the four callbacks its address says it never receives and has them revert NeverCalled(), so the claim is legible on the contract and not only in the address.
function crosses(uint256 leg, int24 target, bool up) internal pure returns (bool) {
(int24 pre, int24 post,,) = unpack(leg);
return up ? (pre < target && target <= post)
: (post <= target && target < pre);
}Half-open at pre, closed at post, in both directions. pre is where the previous leg already left the price, so a target sitting exactly there has been reached already and is not this leg's work; post is where this leg put it, and arriving exactly on the target counts as arriving.
| pre | post | target | up | crosses | why |
|---|---|---|---|---|---|
| 206,700 | 207,100 | 207,000 | true | true | Carried past it on the way through. |
| 206,700 | 207,000 | 207,000 | true | true | Landed exactly on it. Arriving counts. |
| 207,000 | 207,400 | 207,000 | true | false | It was already there when this leg started. Somebody else's work. |
| 206,700 | 206,900 | 207,000 | true | false | Did not get there. |
| 207,100 | 206,300 | 206,400 | false | true | Carried back under it. |
| 207,100 | 206,400 | 206,400 | false | true | Landed exactly on it. |
| 206,400 | 206,000 | 206,400 | false | false | Already there at the start of the leg. |
| 206,700 | 207,100 | 206,400 | false | false | Wrong way. A down errand is only ever satisfied by a down leg. |
Two further checks belong to the board rather than the library: legIndex >= errand.fromLeg, which stops history being mined for work nobody was asked to do, and the hold below, which is the one that matters.
Crossing the target opens the job. It does not finish it. Payment requires a second observation, at least HOLD = 300 blocks after the crossing leg's block, showing the price still past the target.
// claim — the proof is a later leg
if (proofIndex < legIndex || proofBlk < blk + HOLD) revert NotHeldYet();
if (e.up ? heldAt < e.target : heldAt > e.target) revert DidNotHold();
// claimLive — the proof is the pool, right now
if (block.number < uint256(blk) + HOLD) revert NotHeldYet();
if (POOL_MANAGER.getLiquidity(key.toId()) == 0) revert NoLiquidity();
if (e.up ? now_ < e.target : now_ > e.target) revert DidNotHold();Note the comparison at the far end: >= the target for an up errand, <= for a down one — still past it, not merely across it again. And note what is not compared: neither route examines the interval between the two observations. A price that leaves and comes back still qualifies. The property being bought is not continuity, it is that the two observations are 300 blocks apart, and no transaction spans 300 blocks.
MIN_LIFE is 2 × HOLD for the obvious reason: an errand has to be claimable long enough to be carried and held.
post(int24 target, uint96 base, uint64 rate, uint96 escrow, uint48 expiry) → uint256 id
Pulls escrow from the caller with transferFrom and writes the errand. The direction is read from the pool, not passed in. fromLeg is set to the current leg count.
rate is a uint64, so at 18 decimals it tops out at about 18.446 ACTION per block. base and escrow are uint96, which is far above the whole supply.
claim(uint256 id, uint256 legIndex, uint256 proofIndex) → uint256 paid
Permissionless. Settles against a crossing leg plus a later leg proving the price stayed, and pays the runner in the record, never the caller. In one transaction: the whole bounty to the runner, escrow − pay back to the poster, a Waybill minted inside a try, and Ran emitted.
Because the proof is a fact about the past, this route never expires and cannot be raced. A crossing that held remains claimable indefinitely — unless the poster reclaims the escrow through announce and withdraw first.
claimLive(uint256 id, uint256 legIndex) → uint256 paid
The same settlement, proved against the pool's price right now instead of a later leg. Cheaper, and available as soon as it is true.
announce(uint256 id)
Poster only, after block.number > expiry. Sets abandonAt = block.number + GRACE and emits Announced. Public and on chain, so anyone holding a completing leg has a day's warning to claim.
withdraw(uint256 id)
Poster only, no sooner than abandonAt. Returns the whole escrow and marks the errand settled. This and a claim are the only two ways money ever leaves an errand, and there is no early version of either.
quote(uint256 id, uint256 legIndex) → (uint256 pay, address runner)
What the errand would pay if that leg were the crossing, and who would get it. A view. It checks fromLeg but does not check that the leg crosses or that anything held — it answers the money question only.
payNow(uint256 id) → uint256
The same formula against the current block: what it would be worth if the price were carried across in this block. The board's live figure. Reverts NoSuchErrand on an unknown id.
board(uint256 from, uint256 to, uint256 legFrom, uint256 legTo) → (uint256[] ids, bool[] crossed, uint256[] atLeg)
Every unsettled errand in [from, to), and for each one the first leg at or after legFrom that crosses it. Both ranges are paged, because scanning every leg for every open errand is quadratic and a long-lived board would put it past any node's call limit. to or legTo of zero means the end.
crossed is exactly that — crossed, not completed. Whether it held is a separate question, and this view does not answer it. Note also that a claimant may name any qualifying crossing leg, not just this first one, and a later crossing pays more.
ledger() → (uint256 posted, uint256 paid, uint256 returned, uint256 open)
Running totals, where open = posted − paid − returned. Four values rather than five, because nothing is skimmed.
legAt(uint256 i) → (int24 pre, int24 post, address runner, uint48 blk)
One leg, unpacked. Out of range reverts on the array access. legs(i) gives the raw word and legCount() the length.
recentLegs(uint256 n) → uint256[]
The most recent n packed legs, newest last, clamped to the length. For wallets and indexers.
findCrossing(int24 target, bool up, uint256 from) → (bool found, uint256 index)
The first leg at or after from that took the price past target in that direction. A helper for whoever is about to claim: linear, meant for eth_call. The claim itself names the index and costs one read. It answers the crossing question only; the hold is checked at the claim.
poolKey() → PoolKey · isBoundPool(PoolKey) → bool · lastTick() → int24
The pool this hook keeps the record for, a test for it, and where the last leg left the price. Legs are only written for the bound pool; every other pool gets the selector back and nothing else. Errands's constructor uses this pair to check that the bounty token really is the pool's currency1 — asking the hook rather than trusting the deployer — and reverts WrongToken if it is not.
bind(address errands) · issue(...) · tokenURI(uint256) · records(uint256)
bind is callable once, by the deployer, to point the receipt contract at the board — the single privileged action in the whole system, and after it nothing is privileged. issue is callable only by the board. tokenURI returns a base64 data URI with the SVG inside it; no gateway, no server, nothing to keep paying for. The rest is a plain ERC-721.
| Contract | Event | Meaning |
|---|---|---|
| Dispatch | Opened(int24 tick) | The bound pool was initialised and the record was seeded. |
| Dispatch | Carried(uint256 indexed leg, address indexed runner, int24 pre, int24 post) | One leg written. The index is the array position a claim will name. |
| Errands | Posted(uint256 indexed id, address indexed poster, int24 target, bool up, uint96 base, uint96 escrow, uint48 expiry) | A new job, with its terms. |
| Errands | Ran(uint256 indexed id, address indexed runner, uint256 legIndex, uint256 paid) | Settled, by either route. paid is the whole bounty; there is nothing deducted from it. |
| Errands | Announced(uint256 indexed id, address indexed poster, uint48 abandonAt) | The poster intends to reclaim. Anyone holding a completing leg has until abandonAt. |
| Errands | Expired(uint256 indexed id, address indexed poster, uint256 returned) | Nobody claimed in time and the poster took the escrow back. |
| Errands | ReceiptFailed(uint256 indexed id) | The runner was paid but the Waybill mint reverted. The payment is never conditional on the receipt. |
| Waybill | Bound(address errands) | The one privileged call, used. |
| Waybill | Transfer / Approval / ApprovalForAll | Standard ERC-721. A mint is a transfer from the zero address to the runner. |
| ActionLayer | Transfer / Approval | Standard ERC-20. There is no other event, because there is nothing else the token does. |
These are the costs of the design. They are not edge cases and they are not going to be fixed in a later version, because there is no later version: nothing here has an owner or an upgrade path.
Through the Uniswap interface msg.sender is the Universal Router — the same address for every trader alive — so a record made out to it would credit the router for every leg ever carried and be worth nothing. The cost of the alternative is real: if you trade through a smart-contract account, a 4337 bundle, or a Safe module fired by a keeper, tx.origin is not you, and any bounty your trade completes is credited to whoever sent the transaction. Carry from an account you hold the keys to.
The contract cannot cheaply prove that nobody completed a job, so instead it makes the poster announce a reclaim publicly a day in advance. That is time enough for anyone to claim on the runner's behalf — but if literally nobody is watching during the grace period, the escrow goes back to the poster. The claim is permissionless precisely so the watcher does not have to be the runner. It cannot make anybody watch.
Neither claim route inspects the interval between the crossing and the proof. A price that dips back across the target and returns before the claim still pays. What the rule buys is that the two observations are 300 blocks apart, which is what makes an atomic round trip worthless. It is not a guarantee that the price sat still.
And does not care. It pays for the state. A runner may well have been going that way anyway, and will be paid exactly the same as one who went deliberately. If you want to pay only for deliberate work, this is the wrong mechanism.
So a poster carries price risk on their own bounty for as long as it sits there, and a runner is paid in the token of the pool they just moved. Both of those are exposures, and neither is hedged by anything in these contracts.
Nothing prevents it. It loses money — they pay the pool fee and the spread to move the price, and carry the inventory for an hour, in order to receive their own escrow back — but it is possible, and anyone reading a board should assume some of it is posters talking to themselves.
Once posted, the escrow is committed until the poster's own chosen expiry — at least 600 blocks away — and then for a further 7,200 blocks after the announcement. If you post a job and immediately change your mind, you wait about a day and a half at best.
The board sends the pool business and takes nothing from it. There is no tip, no donation, and no share of a bounty for providing — the earlier draft that had one was removed because claim is permissionless, so the caller could choose the instant the donation landed and take it with a one-block position. If you provide here, you are paid the ordinary swap fee and nothing else.
No mainnet address. No testnet address. No audit. No liquidity, no pool, no legs and no errands. The contracts compile and 57 tests pass, including the attack above run against a mainnet fork. That is the whole of the claim being made here, and any address presented anywhere as one of these contracts is not one.
Unaudited Solidity can be wrong — this design has already had one critical flaw found in it, by review, and the fix is what the page above describes. Providing liquidity to any Uniswap pool exposes you to adverse selection whatever the hook does. Moving a price on purpose and holding it for an hour means paying the spread and the fee to do it and carrying inventory while you wait, and there is no guarantee that a bounty exceeds that cost — the pay climbing over time is the only mechanism offered for that, and it climbs to a ceiling and stops. Nothing on this page is advice, and no return is promised by any of it.
The good ones are the ones that sound like an accusation. One of them found a hole big enough to empty the board, which is why the mechanism is what it is.
You could, and against the first version of this contract it worked: one transaction, 1,950 of 3,000 posted tokens, price ending where it started. That is why a crossing no longer pays for anything on its own.
The job is completed by the price being past the target and still past it 300 blocks later. No transaction spans 300 blocks, so there is no atomic version of it. To collect you have to carry the inventory through those blocks in public, where the market can take the other side of you — which is exactly the work being bought.
No, and the difference is the whole idea. A limit order trades your tokens: it puts you on the other side of the move, and when it fills you own something you did not own before. An errand pays somebody else to move the price and never takes a position at all. The poster ends the transaction holding less ACTION and no exposure to the pair.
They also fail differently. A limit order that nobody hits just sits there. An errand that nobody runs gets more expensive every block until somebody finds it worth doing, and returns to the poster if nobody ever does.
There is nothing to stop, because there is no cancel. No function on any of these contracts takes an escrow back before the expiry the poster chose when they posted, and the contract refuses an expiry closer than 600 blocks.
Even then it is two steps: announce, publicly, and withdraw no sooner than 7,200 blocks later. A cancel button is a button for pulling the money in the same block as the transaction that earns it, and the runner has to carry the price for an hour before they can collect. They are owed the certainty that the job is still there when the hour is up.
If nobody claims during it, yes, and that is stated in the risks rather than buried. The contract cannot cheaply prove that no leg completed the job, so it makes the poster announce the reclaim publicly a day in advance instead of guessing.
What makes that survivable is that claim is permissionless and always pays the runner in the record. Anybody — a watcher, a bot, a competing poster, someone who just likes the contract — can settle it on the runner's behalf, and gets nothing for doing so beyond the satisfaction. The runner does not have to be awake. Somebody does.
Then the pay rises — base + rate × blocks, every block, up to the escrow you committed — until somebody finds it worth the capital, the spread, and an hour of inventory risk. An errand nobody wants is an errand that is not paying enough yet.
If it still goes undone by the expiry you set, you announce, wait a day and withdraw, and the whole escrow comes back.
Yes, at a loss. You post the escrow, move the price yourself — paying the pool fee and the spread to do it — hold the position for an hour while the market is free to take the other side, and the claim hands you back your own money. You are strictly worse off than if you had done nothing, and you have carried real risk for the privilege.
What you cannot do is make it profitable by being clever about timing. The payout is capped by your own escrow and the remainder returns to you either way.
An earlier draft skimmed 2.5% off every bounty and donated it to whoever was in range. It sounds generous. It is not: claim may be called by anyone at any moment, so the caller chooses the instant the donation lands, and a bot that mints a tight-range position, calls the claim and burns it takes the whole tip having provided liquidity for one block.
A payment whose recipient is chosen by whoever calls the function is not a payment to liquidity providers; it is a bounty on calling the function. So it was deleted. The pool is paid the way pools are paid: the trade that carries the price pays the ordinary fee, to whoever was actually there to fill it.
Yes, and the flags were chosen for it. There is no beforeInitialize, so the app can open the pool. There are no liquidity gates, so the app can mint and burn positions normally. There is no beforeSwap and no returned delta, so a swap through the app is an ordinary swap: same quote, same fill, no hook data required, 28,411 gas more.
The hook cannot refuse your trade even if it wanted to. Both of its callbacks run after the thing they observe.
The usual warning is about authorisation — using tx.origin to decide who may do something, which is phishable, because a contract you call can call on to something that trusts your origin. Nothing here authorises anything on it. It is used to write a name in a receipt, and there is no action that reading the receipt permits.
The alternative is worse, not safer. Through the Uniswap interface msg.sender is the Universal Router, which is the same address for every trader alive, so a record made out to it would credit the router for every leg ever carried.
The real cost is stated plainly: if you trade through a smart-contract account, the bounty goes to whoever sent the transaction, not to you. Carry from an account you hold the keys to.
Both, and both pay the same runner — provided the price held past both targets. Errands are settled one at a time, each against the leg index it was carried by, and nothing about one claim affects another. One trade through a busy board can complete several jobs and mint several waybills to the same address.
There is no owner on any of these contracts, no upgrade path, no pause, and no address in Dispatch that can be changed after deployment. Dispatch holds no balance at all. Errands holds escrows and has no function that moves them anywhere except to the runner in the record or back to their poster.
The single privileged action in the system is Waybill.bind(), which the deployer may call once to point the receipt contract at the board. Once bound it cannot be rebound, and nothing is privileged after that. Even that one call is not load-bearing: the mint is wrapped in a try, so an unbound Waybill costs you a picture, not a payment.
The token is an ERC-20 with permit and burn and nothing else: one billion, eighteen decimals, minted once in the constructor, no mint function, no owner, no tax, no pause, no blacklist, no fee on transfer, no upgrade path. Where the supply goes at launch is a deployment fact, and since nothing is deployed there is no honest claim to make about it here.
Nowhere. There is no mainnet address, no testnet address, and no audit. If you find an address claiming to be one of these contracts, it is not one.