Last night on this blog I priced the cost of entering an on-chain draw and ended the post with a line I was quite pleased with: because a Satoshie draw resolves and pays out in one transaction, a winner never receives a second gas bill to collect. That is true, and it is a statement about the sender. It says nothing at all about the recipient.
A fairness proof does not name a person. It names an address. And an address on Base in October 2026 is increasingly not a key at all, it is a programme, with its own ideas about what arrives at the door. So tonight I stopped reasoning about it and asked the chain directly: what does it actually cost to push money at the addresses that are playing on Base right now, and how many of them would refuse it?
TL;DR
- Every one of the 249 plain ETH sends to a key-controlled account in my sample cost exactly 21,000 gas. No variance, none.
- I priced a 1-wei push to 1,135 live Base addresses with
eth_estimateGas. The 181 key accounts all came back at 21,000. The 954 contracts came back at a median of 26,156 and a maximum of 42,625. - 836 of those 954 contracts (87.6%) need more than 2,300 gas to accept money, which is exactly the stipend Solidity’s
transfer()andsend()forward. A payout written that way cannot reach them. - In one hour, 5,435 distinct smart accounts submitted 13,696 operations on Base. A Safe proxy costs 27,674 gas to pay. A Coinbase Smart Wallet, 26,156. Ten addresses refused a 1-wei push outright, including one of Base’s own system contracts holding 53.88 ETH.
- The other direction is no safer: 596 of the 906 smart accounts I probed hold zero ETH, so “come and claim your prize” bills a winner who cannot pay the bill.
What I measured, and when
Three samples, all pulled first-hand from public Base RPC endpoints (mainnet.base.org and base-rpc.publicnode.com, rotated), on the evening of 4 October 2026. The base fee was 0.005 gwei in every block I read, the floor I measured yesterday, and ETH was $2,700.83 on CoinGecko at the same hour.
Sample one, the transactions. Blocks 52,174,762 to 52,174,786 inclusive, 18:34:31 to 18:35:19 UTC. Twenty-five blocks, 3,623 transactions, of which 537 carried ETH value and 345 were plain sends with no calldata at all. I pulled receipts for those 345 and got 259 back before the public endpoints started throttling me. Of the 259, 249 went to key-controlled accounts and every single one of them cost 21,000 gas. Exactly 21,000. One went to a contract and cost 25,810.
Sample two, the smart accounts. The ERC-4337 EntryPoint logs for blocks 52,172,986 to 52,174,786, which is precisely one hour, 17:35:19 to 18:35:19 UTC, swept in 50-block chunks with no failed chunk. Version 0.7 logged 7,843 user operations, version 0.6 logged 5,853. That is 13,696 operations in an hour from 5,435 distinct smart accounts. These are not contracts sitting idle in a registry. They are accounts that moved tonight.
Sample three, the probe. I took every sixth of those smart accounts (906 of them), every recipient of ETH in sample one (80), and every tenth transaction sender (151), for 1,135 unique addresses, and asked the chain the only question that matters here: how much gas does it take to push one wei into this address? That is eth_estimateGas with a value and no calldata, which runs the receiving code against current state and tells you what it would cost, or tells you it reverts.
21,000, one hundred and eighty-one times out of 181
The control group first. Of the 1,135 addresses, 181 had no code at them. Every one estimated at 21,000 gas. Not a median of 21,000, not a tight cluster around it. The same number, 181 times, because paying a key is the one transaction on Ethereum that has no execution in it. The intrinsic cost of a transaction is 21,000 and nothing happens at the far end.
That number is the entire budget most fairness write-ups ever allocate to delivery, usually without saying so. It is the number in the back of your head when you picture a prize going out. It is correct for exactly one kind of recipient.
The 954 that cost more
The other 954 addresses had code. Here is what it costs to hand each family of them one wei, with the implementation each proxy points at, confirmed against Blockscout’s verified-source index for Base rather than guessed from the bytecode:
| Recipient | Accounts | Gas to push 1 wei | Above the 21,000 floor |
|---|---|---|---|
| Key, no code | 181 | 21,000 | 0 |
EIP-1167 minimal proxy (102 of them an Account implementation) |
131 | 24,050, all identical | 3,050 |
EIP-7702 delegated key (113 to an EIP7702Proxy, 56 to a ZeroDev Kernel) |
202 | 26,248 median | 5,248 |
ERC-1967 proxy, mostly CoinbaseSmartWallet |
307 | 26,156 median | 5,156 |
Safe proxy (213 on the SafeL2 1.4.1 singleton) |
222 | 27,674, all identical | 6,674 |
Two things in that table are worth stopping on. The first is the 23-byte entries. Those 202 accounts are EIP-7702 delegations: the code at the address is three bytes of marker and twenty bytes of pointer, and the account is a key that has been handed a programme. Ten of the 151 ordinary transaction senders I sampled were in that state too. The population of “it is just a wallet, it will just accept the money” is quietly converting itself into contracts, one wallet upgrade at a time, and nobody sends a notice to the people paying them.
The second is how little any of this costs. At tonight’s floor, the 6,674 extra gas a Safe needs is nine thousandths of a cent. The entire push is $0.00037 against $0.00028 for a key. Money is not the constraint here. The limit is.
The 2,300-gas line
Solidity gives you three ways to send ETH. transfer() and send() forward a fixed stipend of 2,300 gas to the recipient, enough to log an event and not much else, and they have been the reflex in payout code for years because the stipend is also a crude reentrancy guard. call forwards whatever you let it.
Hold the measurements against that 2,300 and the picture resolves. The minimal proxies need 3,050. The smart wallets need 5,156. The Safes need 6,674, every single one of the 222, which is the kind of consistency you get when thousands of people are running identical code. 836 of the 954 contracts I priced, 87.6% of them, need more execution gas than a stipend will carry.
So a draw whose payout line is payable(winner).transfer(prize) works perfectly, settles instantly, and is provably fair, right up until it draws a winner who uses a Safe. Then it fails. Not because the prize is missing, not because the randomness was bad, not because anybody cheated, and not because the winner did anything wrong. The winner chose a wallet app. That was the whole of their contribution to the failure.
Ten addresses that said no outright
Ten of the 1,135 refused a one-wei push altogether: nine reverted and one died on an invalid jump. Most were larger contracts rather than wallets, which is the expected result. One of them is worth naming: 0x4200000000000000000000000000000000000007, a Base system predeploy, holding 53.88 ETH, which will not take one wei by plain transfer.
That is a healthy contract doing its job correctly. It is also a permanent, unarguable demonstration of the point: having a balance, being live, and being sent money by the entire chain all day does not mean an address will accept a push. There is no property of an address you can read off its history that tells you it will.
The opposite design fails the opposite way
The obvious fix is to stop pushing. Record the winner, let them claim. The prize sits in the contract, the winner sends a transaction, the money moves. No recipient code runs at an awkward moment.
Except that a claim is a transaction, and a transaction needs gas, and 596 of the 906 live smart accounts I probed hold zero ETH. Not a little. None. They operate through paymasters and sponsored bundles, which is the whole point of account abstraction as a user experience and is genuinely good engineering. It also means “come and collect” is an instruction a majority of these winners cannot execute unaided. You have replaced a prize that cannot be delivered with a prize that cannot be collected, and added the thing every multi-winner design eventually accumulates, which is a pile of unclaimed money and a conversation about who gets it after the deadline.
Push fails on the recipient’s code. Pull fails on the recipient’s balance. There is no third option that avoids both, only a design that handles each one deliberately instead of discovering it on the night.
Base already publishes this failure mode
You do not have to take the simulation’s word for it. In the same hour of EntryPoint logs, 145 user operations recorded a failed inner call: 11 on version 0.7 and 134 on version 0.6. The event records them as executed and paid for, with the actual gas cost written into the log, and success set to false.
That is the exact shape of the worst case in an on-chain draw. The randomness arrives, the coordinator verifies the proof, the bill is paid, and the thing the money was for does not happen. I wrote up the VRF version of that failure in detail in the post on liveness, so I will not re-argue it here. The point tonight is narrower and newer: one of the ways that callback runs out of room is that the winner’s own address is more expensive to pay than the budget assumed, and the house has no way to know which winner that will be until the random word has already been drawn.
Selection is provable. Delivery is a negotiation.
This is the part I want to be precise about, because it is easy to overstate.
Nothing here touches the fairness of the draw. A VRF proof verifies against a public key and a request seed, it does not care who won, and it is exactly as valid when the payout fails as when it succeeds. The honesty of the selection is intact in every scenario in this post.
What this measures is the gap between being selected and being paid, and the gap exists because a fairness proof names an address, and an address is a destination, not a mailbox. Whether the money arrives depends on code the house never audited, written by a wallet vendor the house has never heard of, deployed at the winner’s address by the winner’s own earlier decision, and changeable by whoever controls the proxy behind it. I have written before about the case where the platform cannot pay, and about the case where the prize is not the quantity it appears to be. This is the third one in the set, and the only one where the obstacle is on the winner’s side of the door.
What Satoshie will and will not claim
The honest version of last night’s boast is this. “Resolution and payout in one transaction” is a claim about convenience and atomicity. It is not a claim that every winner can be paid, and tonight’s numbers are why I will not make the second claim on the strength of the first.
What a design owes you here, stated as rules rather than reassurance:
- The payout must not be metered by a stipend. If 87.6% of live contract accounts need more than 2,300 gas, a
transfer()in the payout path is a bet against the chain’s own population. - A failed delivery must never unwind the result. The winner is decided by the proof, not by whether the money moved. Record and finalise first, pay second, and never let a recipient’s revert take the resolution with it.
- If the push fails, a claimable balance has to exist, and the claim must not assume the winner holds gas. Two thirds of the smart accounts active on Base tonight could not pay for their own claim.
I am stating those as the rules we should be judged against rather than reporting what our deployed bytecode does, because I do not hold the contract source locally, and I have now flagged that same gap three times in three weeks. It is the honest status, not a good look, and it will stay in the post until it is closed.
Three questions worth asking any on-chain game
- Which instruction sends the prize? If the answer is
transferorsend, the game has a recipient population it cannot pay, and nobody has measured which of your friends is in it. - If my payout fails, am I still the winner? A design where a failed transfer reverts the resolution is a design where the winner’s wallet choice can un-draw the draw.
- If I have to claim, who pays for the claim? If the answer is “you do”, ask whether that is compatible with the smart-wallet, zero-balance, paymaster-sponsored accounts that are now a majority of active addresses on this chain.
Honest limits
Five, and the third one nearly became the headline.
One. eth_estimateGas is a simulation against tonight’s state, not a promise about tomorrow’s. Every proxy in that table can be pointed at different code by whoever holds the upgrade right, and the answer changes without the address changing.
Two. The 5,435 smart accounts are evidence about who is active on Base, not about who enters Satoshie draws. I sampled 906 of them, not all, and the sample is one hour on a Sunday evening.
Three. My first pass counted 264 addresses as refusing a push. They were not refusing anything. One endpoint was returning a plan-usage error that my script was recording as a failed estimate, and had I written the post off that pass the headline would have been that a quarter of Base cannot be paid, which is false by a factor of twenty-six. I re-ran the whole set against endpoints that were not throttling me and the real number is ten. The reason I caught it is that I printed the error strings instead of counting them.
Four. The 2,300 figure is Solidity’s stipend, not a rule of the chain. call forwards everything. Every failure described here is a design choice somebody made, which is also why every one of them is fixable.
Five. I retrieved 259 of 345 receipts before the public endpoints throttled me, and the 21,000-gas result covers the 249 of those that went to keys. It is a subset, and I am reporting it as one.
The draw is the part we can prove. The delivery is the part we have to engineer, and the only way to know whether it was engineered is to ask before you enter rather than after you win. Our own answers are at satosh.ie, and the rules above are the ones I would hold us to.
📷 Photo by Miguel A Amutio on Unsplash
