Motivation
Consumer fee pool addresses are deterministic, unregistered module-style accounts (authtypes.NewModuleAddress("provider-consumer-fee-pool-<id>")) — see GetConsumerFeePoolAddress in x/vaas/provider/keeper/fees.go. Because no private key can produce these addresses and they are not registered as module accounts, the only programmatic way to drain them is CollectFeesFromConsumers, which only runs for LAUNCHED consumers.
Cases the current design cannot recover from:
- Funds sent to a fee pool with the wrong denom (operator pays in
uatone instead of uphoton).
- Over-funding before the consumer is removed: the residual sits there forever.
- Funds in pools of consumers deleted before any auto-sweep was added.
- Any other operator mistake or accounting cleanup.
A governance-gated refund message lets the chain unstick these without touching the protocol or running migrations.
Proposed change
Add MsgRefundConsumerPool to x/vaas/provider:
- Authority:
gov module address (proposal-only).
- Fields:
consumer_id, recipient, amount (or omit amount to drain everything).
- Handler:
SendCoinsFromAccountToModule(feePool, providerModule, amount) then SendCoinsFromModuleToAccount(providerModule, recipient, amount). Direct path is fine if the bank keeper exposes it.
- Validate-basic: non-empty consumer_id, valid recipient, positive amount (or empty for drain-all).
- CLI command + tx codec +
RegisterInterfaces.
- Unit test for the keeper handler; e2e covering a successful gov-proposal refund.
Scope notes
- Does not require the consumer to be deleted — useful mid-life for over-funding refunds too.
- Independent of any auto-sweep on
DeleteConsumerChain. The two are complementary: sweep handles the happy-path deletion case automatically, this msg handles arbitrary recovery.
- The recipient is carried in the proposal, so no new on-chain state for "creators" is needed.
Out of scope
- Auto-sweep on consumer deletion (separate concern; can land independently).
- Refund-to-original-funder semantics (bank doesn't track funders; not worth introducing per-tx accounting just for this).
Related
Motivation
Consumer fee pool addresses are deterministic, unregistered module-style accounts (
authtypes.NewModuleAddress("provider-consumer-fee-pool-<id>")) — seeGetConsumerFeePoolAddressinx/vaas/provider/keeper/fees.go. Because no private key can produce these addresses and they are not registered as module accounts, the only programmatic way to drain them isCollectFeesFromConsumers, which only runs for LAUNCHED consumers.Cases the current design cannot recover from:
uatoneinstead ofuphoton).A governance-gated refund message lets the chain unstick these without touching the protocol or running migrations.
Proposed change
Add
MsgRefundConsumerPooltox/vaas/provider:govmodule address (proposal-only).consumer_id,recipient,amount(or omitamountto drain everything).SendCoinsFromAccountToModule(feePool, providerModule, amount)thenSendCoinsFromModuleToAccount(providerModule, recipient, amount). Direct path is fine if the bank keeper exposes it.RegisterInterfaces.Scope notes
DeleteConsumerChain. The two are complementary: sweep handles the happy-path deletion case automatically, this msg handles arbitrary recovery.Out of scope
Related
feat(x/provider): withdraw funds from consumer pool address at each block) introduced the fee pool addresses this issue refunds.