The moment your paymaster sponsors gas, every user click spends your money — which makes per-user metering, budgets and abuse limits product features, not infrastructure options. An unmetered sponsor is a faucet with your logo on it.
Attribute every sponsored operation to a user and an action, roll it into a live cost dashboard against a daily budget, then run a bot against the unmetered version and watch the budget die.
Why
Gasless UX is table stakes for consumer on-chain apps, and it has a precise accounting meaning: gas moved from the user's cost line to yours. Cloud spend taught this lesson already — an unmetered resource that users can trigger is a bill someone else writes. The difference on-chain is that the trigger is permissionless: anyone can generate wallets and click.
So the sponsor needs what every payments company runs internally: attribution (which user, which action, how much), budgets (per-user daily caps, a global kill line), and pricing awareness (an action costing 40 cents of gas to earn 2 cents of revenue is a business decision someone should see). None of this exists at the protocol layer — ERC-4337 defines how a paymaster pays, not when it should refuse. The refusal policy is the product.
How it works
Attribution on every UserOp, a budget with a kill line, and a bot that proves why.
PoC
On a 4337 stack (thirdweb or self-relay on anvil): wrap sponsorship so every sponsored UserOp records { user, action, gasUsed, costWei, timestamp }. Dashboard: cost per user, per action, cumulative against a daily budget; a global pause when the budget line is crossed and a per-user cap (say 20 sponsored ops/day) that degrades that user to pay-your-own-gas instead of blocking them. Then the red team: a script generating 200 fresh wallets hammering the cheapest sponsored action against the unmetered build — chart minutes-to-budget-death — and again against the metered build, where the caps hold and the burn flatlines.
What it proves
Sponsorship policy is spend control over a permissionless trigger, and the three pieces — attribution, budget, degrade-not-block — are the whole mechanism. It also surfaces the honest unit economics per action, which is the number that decides whether gasless is a growth cost or a slow leak. Extends bundler-paymaster-dependencies from whom you depend on to what it costs you.
페이마스터가 가스를 대납하는 순간 사용자의 모든 클릭이 당신 돈을 씁니다 — 그래서 사용자별 계량, 예산, 남용 제한은 인프라 옵션이 아니라 제품 기능입니다. 계량 없는 스폰서는 당신 로고가 붙은 파우셋입니다.
대납된 모든 오퍼레이션을 사용자와 액션에 귀속시키고, 일일 예산 대비 라이브 비용 대시보드로 집계한 뒤, 무계량 버전에 봇을 돌려 예산이 죽는 것을 관찰합니다.
왜
가스리스 UX 는 소비자 온체인 앱의 기본값이고, 정확한 회계적 의미를 갖습니다: 가스가 사용자의 비용 줄에서 당신 비용 줄로 이동했다. 클라우드 지출이 이미 가르친 교훈입니다 — 사용자가 트리거할 수 있는 무계량 자원은 남이 써 주는 청구서입니다. 온체인의 차이는 트리거가 무허가라는 것: 누구나 지갑을 만들어 클릭할 수 있습니다.
그래서 스폰서에게는 모든 결제 회사가 내부에서 돌리는 것이 필요합니다: 귀속(어느 사용자, 어느 액션, 얼마), 예산(사용자별 일일 상한, 전역 킬 라인), 그리고 가격 감각(2센트 벌자고 40센트 가스를 쓰는 액션은 누군가 봐야 할 사업 결정입니다). 이 중 무엇도 프로토콜 계층에 없습니다 — ERC-4337 은 페이마스터가 어떻게 내는지를 정의하지 언제 거절해야 하는지는 정의하지 않습니다. 거절 정책이 곧 제품입니다.
동작 방식
모든 UserOp 에 귀속, 킬 라인이 있는 예산, 그리고 이유를 증명하는 봇.
PoC
4337 스택(thirdweb 또는 anvil 셀프 릴레이)에서: 대납을 감싸 모든 스폰서드 UserOp 이 { user, action, gasUsed, costWei, timestamp } 를 기록하게 합니다. 대시보드: 사용자별·액션별 비용, 일일 예산 대비 누적; 예산 라인을 넘으면 전역 일시정지, 사용자별 상한(예: 일 20 스폰서드 오퍼레이션)은 차단이 아니라 자기 가스 지불로 강등. 그다음 레드팀: 새 지갑 200개를 만들어 가장 싼 스폰서드 액션을 무계량 빌드에 때리는 스크립트 — 예산 사망까지의 분을 차트로 — 그리고 계량 빌드에 다시: 상한이 버티고 소진이 수평선이 됩니다.
무엇을 증명하나
대납 정책은 무허가 트리거에 대한 지출 통제이고, 세 조각 — 귀속, 예산, 차단 아닌 강등 — 이 메커니즘의 전부입니다. 액션별 정직한 단위 경제도 드러납니다 — 가스리스가 성장 비용인지 느린 누수인지 결정하는 바로 그 숫자. bundler-paymaster-dependencies 를 “누구에게 의존하나”에서 “그것이 얼마가 드나”로 확장합니다.