Thanks everyone for the input so far. Let me provide more details.
Data sources
This is the most important piece. Unfortunately the only way to get precise rebate information I am aware of is to run a script against an archival node. Dune does not have exact information required, so the table in the original proposal is produced using this query. It tracks the maximum potential rebate, best effort estimate of the real rebate (subtracting some non-rebated gas burn), and the total number of unique contracts called in the time period. Even for an aggregate view across last 12 months it times out more often than not, so the best metric that I was able to collect for this time span is average per contract. For better understanding I dug into shorter time periods and will be sharing more detailed results for May (latest complete month) and October (anomalous number of unique contracts used). Let me know if you spot inaccuracies in the queries.
Global Contracts
Even if the developers come up with a sweep function they need to call it on hundreds of thousands of accounts to collect <1 milliNEAR from each. October last year was a month with 223,698 unique contracts called. 220,379 of them were XXXX.craft.tg, the most popular of them was called 35 times and accumulated at most 1.76 milliNEAR. They were all using global contract trading-zone-gc.tg, served 270,375 calls and accumulated no more than 34 NEAR. A trading app with 0.1 onchain TPS collected at most 1 NEAR per day. And to get that 34 NEAR developers would need to sweep 220k accounts - I am leaving to the reader to calculate the cost of it. Yes, more contracts is bad for the current rebate model.
Another important point, global contracts are normally deployed by users to the accounts they control. They have full access keys for those accounts and may have NEAR balance as well. They may frontrun the developers. And blindly sweeping full balance means stealing from them.
Also, above proves that global contracts are very much used.
Sharded Contracts
Sharded contracts use global contracts and have the same sweeping problem. It is a newer feature and is not widely used yet, although e.g. Intents team no longer writes non-sharded contracts at all. And for a good reason. Non-sharded contracts do not have future. They are stuck to a single shard and cannot be split if they reach the limit. There are 2 major scaling factors for contracts: TPS and storage. NEAR’s per shard TPS is pretty high and even the most used contracts are somewhat far from the limit at the moment. The storage is a very different story. Aurora uses 13.71 GB of storage and keeps growing. It is already so big that it has a dedicated shard just for it and it is getting close to the limit of what a single shard can handle. There is no way forward after that without using sharded contracts. intents.near is much younger, but grows much faster and is already at 9.20 GB. It was 8.18 GB last month. These contracts will have to migrate to sharded contracts very soon. And if you aim at any decent adoption you should stop writing non-sharded contracts today.
Per Contract rebates
Here is a per contract rebate query, sorted from the highest. Copying the first page for simplicity:
| month | account | rebate_upper_bound_near | rebate_estimate_near |
|---|---|---|---|
| 2026-05-01 00:00:00 | v2.jars.sweat | 939.43006270111 | 787.979872472734 |
| 2026-05-01 00:00:00 | claim.sweat | 918.725359475307 | 805.875006924759 |
| 2026-05-01 00:00:00 | game.hot.tg | 542.078916925404 | 317.042112966482 |
| 2026-05-01 00:00:00 | token.sweat | 502.119100532959 | 224.708568736626 |
| 2026-05-01 00:00:00 | v1.signer | 469.843902440916 | 365.162099907591 |
| 2026-05-01 00:00:00 | intents.near | 469.320789061813 | 377.539174837087 |
| 2026-05-01 00:00:00 | sweat.jwt.fast-auth.near | 464.5463790268 | 444.625866326288 |
| 2026-05-01 00:00:00 | dclv2.ref-labs.near | 437.255989973556 | 364.721162714801 |
| 2026-05-01 00:00:00 | aurora | 421.574493122567 | 375.382979449951 |
| 2026-05-01 00:00:00 | v2.ref-finance.near | 415.459706971659 | 293.834488037747 |
| 2026-05-01 00:00:00 | btc-connector.bridge.near | 169.198345212573 | 158.434344913327 |
| 2026-05-01 00:00:00 | wrap.near | 165.430441359832 | 44.7704426868291 |
| 2026-05-01 00:00:00 | pyth-oracle.near | 130.048860388951 | 79.3190137882047 |
| 2026-05-01 00:00:00 | fast-auth.near | 117.607547544798 | 42.4552077882615 |
| 2026-05-01 00:00:00 | 17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1 | 93.6357822830427 | 43.243143706957 |
| 2026-05-01 00:00:00 | v2_1.omni.hot.tg | 93.2815300155812 | 60.5213131141285 |
| 2026-05-01 00:00:00 | jars.sweat | 79.1509989355846 | 76.2506278872496 |
| 2026-05-01 00:00:00 | aa-harvest-moon.near | 66.8311706948639 | 38.6379776197929 |
| 2026-05-01 00:00:00 | jwt.fast-auth.near | 61.8963236802213 | 16.9227167640358 |
| 2026-05-01 00:00:00 | usdt.tether-token.near | 45.0789497614927 | 15.1470927248217 |
| 2026-05-01 00:00:00 | zec.omft.near | 36.3937466762795 | 12.0258513544999 |
| 2026-05-01 00:00:00 | contract.wormhole_crypto.near | 35.5286994260362 | 28.2870720479062 |
| 2026-05-01 00:00:00 | meta-pool.near | 33.1626912293811 | 26.4567127958578 |
| 2026-05-01 00:00:00 | client-eth2.bridge.near | 30.9572961636255 | 25.2719587685355 |
| 2026-05-01 00:00:00 | firedrop.hot.tg | 30.6172551920528 | 24.3794294986928 |
Only 14 contracts cleared 100 NEAR per month bar, 25 contracts got 30 NEAR or more. I am pretty sure none of them treats this as a meaningful revenue stream and for most of them I know it from talking to the teams.
You can find dex.intear.near at the page 2, row 40 with 8.5 NEAR rebate btw.