Nullfill
An escrow for Robinhood Chain that doesn't strand your money when a transaction is screened at the sequencer.
Video
Công nghệ sử dụng
Sự miêu tả
Nullfill is an escrow for Robinhood Chain that stays correct when a transaction is screened at the sequencer and never sequenced. It settles in USDG, it's live on Robinhood Chain testnet, and two real USDG orders have gone through it.
Live console: https://iamrobertmoore.github.io/Nullfill/
Contract: 0x71029fac49E9b45CCC377812aEc01509FFD383A1 (Robinhood Chain testnet, 46630)
Code: https://github.com/iamrobertmoore/Nullfill
Pitch deck: https://iamrobertmoore.github.io/Nullfill/deck/
Real Problem Solving
Robinhood Chain screens transactions before they're sequenced. A screened transfer leaves 0 bytes on chain: no revert, no receipt, no event, no gas. The chain's own docs put it plainly: "Since a blocked transfer is never processed, it simply appears as though the event never occurred."
For 24 hours nobody can tell blocked from late, because that's the force inclusion window, in which the missing transaction can still arrive. Any contract that acts on "nothing arrived" before then is acting on a guess.
It matters because of what's held on this chain. 672.9 million USDG sits on Robinhood Chain mainnet (read from the token contract at block 74,889,519 on 28 September 2026).
And the filter isn't theoretical. Robinhood Chain keeps a registry of the transactions its compliance filter refused, at the ArbOS precompile 0x74. Between 30 June and 16 September 2026 it recorded 1,355 of them on mainnet. Those are only the ones that came in through the delayed inbox and were failed on arrival. A transaction refused at the sequencer's door isn't counted anywhere, and that's the case Nullfill is built for.
So on 28 September I read the settlement contracts in this buildathon that hold people's funds and whose source I could find. There were eight. None handles a transaction rejected at the sequencer. Three move money when a transaction doesn't arrive by a deadline, and in two of those the deadline can be set under 24 hours. I'm not naming anyone; the point is the pattern.
Innovation and Creativity
Every escrow I know of assumes a submitted transaction either lands or reverts. Nullfill treats a third outcome, that it never happened, as a settlement state it has to handle. On 30 September I checked all 105 projects in this buildathon. One other works with the compliance filter, for corporate action updates. None treats a missing transaction as a settlement outcome.
Novelty, stated plainly because the terms reward it: the screening mechanism is Arbitrum's and is documented. What's new is a settlement design built around it. Recovery never depends on the screened party transacting, and no deadline may sit inside the force inclusion window.
Smart contract quality
Three rules, enforced in a small contract with no owner and no fee:
Anyone can unwind an expired escrow, so getting money back never depends on one party sending a transaction.
The refund address is named when the escrow opens, and can be changed while it's open.
No deadline can sit inside the 24 hour window. The contract refuses one.
Built with OpenZeppelin SafeERC20 and ReentrancyGuard, custom errors, one-way state transitions, and a reference per order so a retried transaction can't pay out twice.
46 Foundry tests, four of them fuzzed, including a property that every micro-dollar of USDG that goes in comes out again. I also mutated the contract 14 ways on purpose. The tests caught 13. The one they missed (halving the 24 hour window) now has its own test.
A separate test checks that the bytecode on chain is exactly what the repository compiles to, byte for byte.
One known limit, stated rather than hidden: the deployed escrow assumes a token transfers exactly what it's asked to. USDG and the testnet stock tokens all do. The fix is written and ships with the next deployment, and a test pins the current behaviour.
Use of Arbitrum technology
Nullfill is built around ArbOS 61 compliance filtering and the Arbitrum force inclusion window, both documented Arbitrum features. I reproduced the screening on a local Nitro testnode with the filter switched on: transactions from and to a restricted address came back with -32000 Transaction rejected by chain policy, balance reads still worked, and a control transaction went through. The full setup is in docs/reproduction.md, including three places where the published docs didn't match the shipped binary. Then I read mainnet: the second layer, which fails a filtered transaction that arrives through the delayed inbox, is live, and its registry at 0x74 lists 1,355 refusals. The console's classifier reads that registry, so paste a mainnet hash and it tells you if the chain filtered it.
USDG
The cash leg is USDG, the stablecoin Robinhood Chain lists on its own ecosystem page. Two real orders of 50 USDG each, from the Paxos testnet faucet, went through the deployed contract:
Order 1, opened then settled: https://explorer.testnet.chain.robinhood.com/tx/0xb3c300d0c5040e7d1023376fb860cdd8f3e1abf7cc8aa06104d7b713d3b8d173
Order 2, unwound after 24 hours by a wallet that never touched it, with the USDG going to the address named at the start: https://explorer.testnet.chain.robinhood.com/tx/0xc814cc0a80e0900b8d5bba01b87f2dd10b27601fd71d959a13103f398def6444
The console reads both statuses from the contract live.
Product-Market Fit
Who it's for: anyone holding funds on Robinhood Chain against a future event. OTC desks settling tokenised equities against USDG, lending protocols with repayment deadlines, protection notes with expiries, payout pools. The survey above found eight in one buildathon.
The escrow stays free and MIT licensed. What I charge for is Nullfill Watch. The alpha is already in the repo: it sits between a wallet and the RPC, keeps a signed receipt of every refused transaction (the sender's error is the only record that exists), lists every escrow an address is party to with its deadline, and asks the chain's 0x74 registry whether it filtered a given transaction. The console verifies a real receipt in your browser, and lets you tamper with it to watch the signature fail. The hosted version adds alerts and bridge-deposit matching: $99 a month per desk, up to 25 watched addresses.
Roadmap: now, the Watch alpha (in watch/). October, v1.1 with the exact-deposit guard and hosted Watch. November, the three rules as a Solidity library other contracts can inherit. Q1 2027, audit, Robinhood Chain mainnet, and an Arbitrum DAO grant application.
Check it in five minutes
The deployment is this source:
ROBINHOOD_RPC=https://rpc.testnet.chain.robinhood.com forge test --match-path test/Deployment.t.solThe window is 24 hours:
cast call 0x71029fac49E9b45CCC377812aEc01509FFD383A1 "FORCE_INCLUSION_WINDOW()(uint64)"returns 86400The contract suite: cd contracts && forge test, 46 passing, 4 skipped (the live-chain checks)
The console suite: cd web && npm test, 26 passing
The watcher suite: cd watch && npm test, 5 passing
A real refusal, signed: node watch/nullfill-watch.mjs verify web/data/sample-receipt.json
Order 1 settled: statusOf(0xfad69ced7f9b1bf95844435440a669de0644dfbf7a378f571f412529e599acee) returns 2
Order 2 unwound by a stranger: statusOf(0x7fb40dea2f7e756989161f233dc86cd0a83d6e98b9558c1e460e20d7a351cc90) returns 3
The screening is real: docs/reproduction.md