[Feature Request]: Add Positive Delta Recipient Support to PoolManager.burn #985
Description
Component
Delta accounting
Describe the suggested feature and problem it solves.
The PoolManager currently credits positive flash accounting deltas from ERC-6909 burns exclusively to the caller (msg.sender). This prevents routing the economic value of a burn to a designated recipient, forcing integrators to build awkward handoffs (e.g., burning claims and transferring them) when settling third-party obligations. Introducing an optional recipient parameter to PM.burn would make it possible to pay down another address’s negative delta directly, streamline settlement flows, and reduce redundant PM.take + PM.sync + ERC20.transfer(PM) + PM.settleFor(recipient) operations.
Describe the desired implementation.
Extend the IPoolManager interface with an overload burn(address from, address recipient, uint256 id, uint256 amount). The existing three-argument signature remains for backwards compatibility and simply forwards to the new overload with recipient = msg.sender. Inside PoolManager, coerce recipient to msg.sender when it is the zero address before applying _accountDelta(currency, amount.toInt128(), recipient) and _burnFrom(from, id, amount).
Describe alternatives.
Status quo requires the burner to receive the positive delta. In order for an integrator to allow a designated recipient to accrue a delta from their ERC-6909 balances we have options:
- integrator grants the recipient a PM ERC6909 allowance or sets it as an operator and the recipient does a
PM.burnto spend from that privilege accruing a positive delta to itself(being the caller of PM.burn) - integrator does a
PM.burn -> PM.take -> PM.sync -> ERC20.transfer(PM) -> PM.settleFor(recipient)accruing a positive delta to the recipient
Both of which introduce coordination complexity. These workarounds increase gas costs, complicate integrations, and leave room for error compared to native support in PoolManager.burn
Additional context.
No response