[PoC] First iteraration of the Dynamic Allocation Pool (DAP): burns -> DAP buffer

[sigurpol]

[DISCLAIMER] This PR is intended as a proof of concept and will not be merged in its current state. Look at #10576 for the first chunk of deliverables we plan to integrate on chain.

📝 Summary

This initial PoC of the Dynamic Allocation Pool (DAP) makes it possible to collect funds that would otherwise be burned, into

• the DAP buffer on AssetHub
• the DAP satellite buffer on the other system chains and the RelayChain
  This is fully configurable, meaning that chains can choose to redirect all, some, or none of the funds that would be burned into DAP.

NOTE: the mechanism to periodically transfer funds from the DAP satellite to the DAP buffer via XCM is not yet in place.

🚀 Events

FundsReturned (pallet-dap) and FundsAccumulated (pallet-dap-satellite) are emitted only for explicit user actions (e.g., burn extrinsic via FundingSink).
Automatic system operations like fee handling and slashes via OnUnbalanced do NOT emit events to avoid bloating blocks with tons of events per block.

⛓️‍💥 Westend

RelayChain and system chains are now integrated with DAP / DAP satellite.

• On AssetHub:
  • treasury unspent and staking slashes are now redirected to the DAP buffer instead of being burned.
  • All user-initiated burns also go to the DAP buffer instead of reducing total issuance.
• On RelayChain, DAP satellite is included, but the original behavior of redirecting 100% of tx fees to the block author is preserved.
• On Coretime, revenues that would be transferred daily to XCM and burned, are now redirected to the DAP satellite instead.
• On other system chains (People, BridgeHub, Collective), DAP satellite is included, but the original behavior of redirecting 100% of tx fees to the staking pot is preserved.

Breaking change: all runtimes must now explicitly configure BurnDestination:

• Non-DAP runtimes should use pallet_balances::DirectBurn<Runtime> for direct burning.
• DAP-integrated runtimes use pallet_dap::ReturnToDap<Runtime> (on AssetHub) or pallet_dap_satellite::AccumulateInSatellite<Runtime> (on other system chains).

🏗️ TODO in the scope of this PR

• 🚧 more tests
• 🙅🏻‍♂️ new benchmarking for dap/dap-satellite: not needed, both pallet-dap and pallet-dap-satellite have no extrinsics. They only provide trait implementations (FundingSink, OnUnbalanced) that other pallets call for which we have ad-hoc benchmarks.

🔜 Coming next (in follow-up PRs)

In the next iterations, we will introduce the following:

• Make it possible to replace direct minting with requesting funds from DAP buffer.
• Make DAP responsible to mint according to the issuance curve defined per chain.
• Make it possible to configure the percentage of funds redirected from DAP to different destinations (validators, nominators, treasury, collators, ...).
• Support for multiple assets in DAP: native token and stablecoin.
• The periodic transfer of funds from DAP satellite to DAP buffer via XCM.

[sigurpol]

/cmd prdoc --audience runtime_dev --bump major

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/20032826136
Failed job name: run-frame-omni-bencher

[Ank4n]

Looking great. My only real question or concern is: should we do a very minimal PR just to stop treasury burn (plus maybe staking slash but thats also rare), and later a bigger change with satellite pallets and potentially moving the minting logic as well inside this pallet? Note that, this will make the audit easier too.

[sigurpol]

Looking great. My only real question or concern is: should we do a very minimal PR just to stop treasury burn (plus maybe staking slash but thats also rare), and later a bigger change with satellite pallets and potentially moving the minting logic as well inside this pallet? Note that, this will make the audit easier too.

That's a very good point. This PR initially was meant to be really a PoC / exploration to try to sketch

• dap
• dap satellite
• minting logic and eventually distribution
• ...

But once I started hooking the dap satellite part, the PR already became pretty big one (and the XCM part is still missing from DAP satellite) - even if changes outside dap / dap_satellite are very minimal.

So I decided to postpone the minting logic for later to avoid to bloat it even more.

I believe your approach to have just DAP in a small PR makes sense since it covers the big source of burning (treasury).
The reason I wanted DAP satellite in some minimal form for 14th March, was to be able to "collect" what we would otherwise burn, especially for coretime revenue. Just collecting w/o necessarily sending back to the main DAP.

But considering it 's not a big amount, I think it's something we can still discuss later and go for a more pragmatic approach:

1. first DAP only with treasury burn and eventually slashing
2. then if we want DAP satellite, we can add it in a separate PR on top

[sigurpol]

I'll keep this PR around as reference for

1. user-initited burns's destination configurable
2. pallet-dap-satellite

but do not spend time in reviewing it furher.

First chunk of changes we plan to have on-chain here -> #10576