Feat/recycle burn chain exts by LandynDev · Pull Request #2560 · opentensor/subtensor

LandynDev · 2026-04-02T19:26:39Z

Description

Add 4 new chain extension functions (IDs 16-19) enabling WASM smart contracts to recycle and burn alpha stake.

RecycleAlphaV1 (16): Recycle alpha stake
BurnAlphaV1 (17): Burn alpha stake
AddStakeRecycleV1 (18): Atomically add TAO stake then recycle
AddStakeBurnV1 (19): Atomically add TAO stake then burn

All functions return the actual alpha amount via the output buffer.

Related Issue(s)

Closes #2564

Type of Change

New feature (non-breaking change which adds functionality)

Breaking Change

No breaking changes. Existing chain extension functions (IDs 0-15) are unaffected. New function IDs 16-19 are additive.

Checklist

I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

Additional Notes

7 unit tests cover: success paths for all 4 functions, root subnet rejection, nonexistent subnet, and insufficient balance. E2E validated on localnet with an ink! contract calling add_stake_recycle via chain extension.

I also ran some local E2E testing with a local running subtensor chain (with the new extensions), deployed contract, etc.

Screenshot 1 shows:

Accumulated fees of 0.0034 TAO on the contract (to be recycled)
Total recycled fees of 0.0000 TAO on the contract
Contract Balance of 5.0000 TAO

Screenshot 2 shows:

Recycle of 0.0034 TAO succeeded (CLI -> Smart contract func -> New add stake + recycle chain ext)
Accumulated fees of 0.0000 TAO on the contract (it got recycled)
Total recycled fees of 0.0034 TAO on the contract
Contract Balance of 4.9966 TAO

Unit tests successfully passing:

open-junius · 2026-04-03T07:35:08Z

Thanks for the contribution. Can you add the ticket for the requirement? I am wondering the extension like AddStakeRecycleV1, who really want to do it. just confirm all is from the real requirements.

LandynDev · 2026-04-03T16:05:56Z

Thanks for the contribution. Can you add the ticket for the requirement? I am wondering the extension like AddStakeRecycleV1, who really want to do it. just confirm all is from the real requirements.

Just got it ticketed up here - #2564

Particular snippet from the issue to elaborate on the AddStakeBurn + AddStakeRecycle funcs and why those 2 are included:

The current AddStakeV1 chain extension only returns a success/error code, not the resulting alpha amount. While a contract could work around this by calling AddStakeV1 followed by RecycleAlphaV1(MAX), this recycles all alpha the contract holds on that subnet — not just the alpha from that specific stake. This is fine for simple contracts, but may break down for contracts that hold alpha for multiple purposes on the same subnet.

The AddStakeRecycleV1 and AddStakeBurnV1 functions handle this atomically in a single call, recycling/burning only the alpha produced by that specific stake. This provides the robustness needed for a general-purpose chain extension interface.

open-junius · 2026-04-07T00:34:24Z

Looks good to me, please fix the 'Cargo fmt'

LandynDev · 2026-04-07T00:41:00Z

Looks good to me, please fix the 'Cargo fmt'

👍
it dismissed your review bc of the repush, but should be good to go now

Strip development log::info!/log::error! calls from dispatch entry and AddStakeRecycleV1 handler. Normalize AddStakeRecycleV1 to use the same concise ? pattern as all other handlers.

… test

LandynDev · 2026-04-07T02:03:40Z

it also needed devnet-ready rebase, got outdated but thats not situated

open-junius

Looks good for me.

LandynDev · 2026-04-07T14:34:11Z

Addressed the review feedback:

Removed redundant .min() clamping in RecycleAlphaV1/BurnAlphaV1. Pallet handles this internally
Wrapped AddStakeRecycleV1/AddStakeBurnV1 in with_transaction for atomicity. If recycle/burn fails, stake is fully rolled back
Added 2 rollback tests (add_stake_recycle_rollback_on_recycle_failure, add_stake_burn_rollback_on_burn_failure)

@evgeny-s / @open-junius if you could give this a re-look when you have a chance, thanks

Commit of changes: 65357d3

open-junius · 2026-04-08T02:06:39Z

+
+                match call_result {
+                    Ok(_) => {
+                        env.write_output(&amount.encode())


I can see you remove the real_amount, and put the amount into result directly. but it could be wrong if the amount is more than you staked. So I suggest we can update the recycle_alpha function with the real recycled alpha as result, or doesn't return any value in RecycleAlphaV1. and the same for burn function.

Good call, I got it updated w this commit - 60dffb3

Trying to keep the diff concise with what i add/change. Reran unit tests and passing

Replaces hardcoded Weight::from_parts values with calls to pallet_subtensor::weights::WeightInfo, matching the pattern junius introduced in PR 2550. Weights now auto-track benchmark updates. AddStakeRecycleV1 sums add_stake() + recycle_alpha() since the pallet has no add_stake_recycle weight; AddStakeBurnV1 uses add_stake_burn() directly (1:1 with pallet's do_add_stake_burn).

open-junius · 2026-04-14T01:52:12Z

+
+                let caller = env.caller();
+
+                let result = transactional::with_transaction(|| {


There is do_add_stake_burn function, can we use it instead of call both do_add_stake and do_burn_alpha

Looked into this but I don't think do_add_stake_burn is usable from a chain ext

It's pub(crate), so it's not accessible from the chain-extensions crate.

Also it calls ensure_subnet_owner on the origin which we won't want

Because of this, I kept it as the do_add_stake + do_burn_alpha composition

open-junius · 2026-04-14T01:53:47Z

+                            <<T as pallet_subtensor::Config>::WeightInfo as SubtensorWeightInfo>::recycle_alpha(),
+                        );
+
+                env.charge_weight(weight)?;


we can charge the add_stake part first. If do_add_stake is Ok, then continue with recycle_alpha weight

Okay, I updated this.. AddStakeRecycleV1 now charges add_stake() upfront and only charges recycle_alpha() after do_add_stake returns Ok. Applied the same split to AddStakeBurnV1 for consistency. Both ops still run inside with_transaction, & tests updated and passing.

For AddStakeRecycleV1 and AddStakeBurnV1, charge add_stake() upfront and only charge the second-stage weight (recycle_alpha()/burn_alpha()) after do_add_stake returns Ok. Atomicity is preserved by keeping both ops inside with_transaction and tracking attempt state via a stack flag.

- cargo fmt wraps the add_stake() call in AddStakeRecycleV1/AddStakeBurnV1 - mock charge_weight replaces saturating_add with checked_add().unwrap() to satisfy the ForbidSaturatingMath custom lint

open-junius

Looks good to me

evgeny-s

I don't like duplicating the composition logic - AddStakeBurnV1 re-implements do_add_stake_burn inline, and AddStakeRecycleV1 introduces a brand-new atomic primitive that doesn't exist as a pallet function at all. Ideally, it would be great to have the functions in the pallet itself and wire them here, something like do_add_stake_burn_permissionless. I still not sure, why we need a guard for the subnet owner, if we can call both functions separately, but this question out of scope for this PR.

@shamil-gadelshin - could you weigh in?

Per your subnet_buyback PR (#2381), the owner-check there is a privilege gate (priority boost + canonical event + per-tempo cadence), not a security control on the underlying effect.

Could you confirm:

That reading is correct, and the underlying atomic add_stake + burn_alpha composition is safe to expose permissionlessly via chain extension?
Are we ok bypassing the rate limit via calling 2 extrinsics separately?

evgeny-s · 2026-04-16T10:52:10Z

+
+                env.charge_weight(weight)?;
+
+                let (hotkey, amount, netuid): (T::AccountId, AlphaBalance, NetUid) =


Can we make arguments order consistent with AddStakeRecycleV1?

evgeny-s · 2026-04-16T11:48:34Z

I don't like duplicating the composition logic - AddStakeBurnV1 re-implements do_add_stake_burn inline, and AddStakeRecycleV1 introduces a brand-new atomic primitive that doesn't exist as a pallet function at all. Ideally, it would be great to have the functions in the pallet itself and wire them here, something like do_add_stake_burn_permissionless. I still not sure, why we need a guard for the subnet owner, if we can call both functions separately, but this question out of scope for this PR.

@shamil-gadelshin - could you weigh in?

Per your subnet_buyback PR (#2381), the owner-check there is a privilege gate (priority boost + canonical event + per-tempo cadence), not a security control on the underlying effect.

Could you confirm:

That reading is correct, and the underlying atomic add_stake + burn_alpha composition is safe to expose permissionlessly via chain extension?

Are we ok bypassing the rate limit via calling 2 extrinsics separately?

The composition function is needed for the priority boost for subnet owners, so it makes sense.

The architectural point about extracting do_add_stake_burn_permissionless / do_add_stake_recycle into the pallet still stands in my opinion. Let's try to extract those as a pallet function and re-use it in the extension, because from what I can see, so far, all the extension functions are thin.

shamil-gadelshin · 2026-04-16T12:11:13Z

The composition function is needed for the priority boost for subnet owners, so it makes sense.

Yes, otherwise it could be MEVed.

LandynDev mentioned this pull request Apr 3, 2026

Smart Contract Recycling Via Chain Ext Function entrius/allways#9

Draft

LandynDev marked this pull request as ready for review April 3, 2026 16:11

open-junius previously approved these changes Apr 7, 2026

View reviewed changes

LandynDev dismissed open-junius’s stale review via e527c74 April 7, 2026 00:40

open-junius added the skip-cargo-audit This PR fails cargo audit but needs to be merged anyway label Apr 7, 2026

LandynDev added 4 commits April 6, 2026 21:00

Burn and Recycle Chain Exts

dda99da

Remove debug logging from chain extension dispatch

8ebf234

Strip development log::info!/log::error! calls from dispatch entry and AddStakeRecycleV1 handler. Normalize AddStakeRecycleV1 to use the same concise ? pattern as all other handlers.

Additional unit tests: Root burn test, Zero amt test, Amount clamping…

94796b0

… test

cargo fmt fix

1c4f180

LandynDev force-pushed the feat/recycle-burn-chain-exts branch from e527c74 to 1c4f180 Compare April 7, 2026 02:01

open-junius previously approved these changes Apr 7, 2026

View reviewed changes

open-junius requested review from JohnReedV, ales-otf, evgeny-s, gztensor, l0r1s, sam0x17 and shamil-gadelshin April 7, 2026 06:17

evgeny-s reviewed Apr 7, 2026

View reviewed changes

Comment thread chain-extensions/src/lib.rs Outdated

evgeny-s reviewed Apr 7, 2026

View reviewed changes

Comment thread chain-extensions/src/lib.rs Outdated

evgeny-s reviewed Apr 7, 2026

View reviewed changes

Comment thread chain-extensions/src/lib.rs Outdated

evgeny-s reviewed Apr 7, 2026

View reviewed changes

Comment thread chain-extensions/src/tests.rs

Address review: remove redundant clamping, add atomicity

65357d3

LandynDev dismissed open-junius’s stale review via 65357d3 April 7, 2026 14:29

open-junius reviewed Apr 8, 2026

View reviewed changes

Return actual recycled/burned alpha amount from pallet

60dffb3

LandynDev requested review from evgeny-s and open-junius April 8, 2026 16:22

open-junius reviewed Apr 14, 2026

View reviewed changes

LandynDev added 2 commits April 13, 2026 21:44

Fix CI: rustfmt wrap and forbid-saturating-math in mock

089a24a

- cargo fmt wraps the add_stake() call in AddStakeRecycleV1/AddStakeBurnV1 - mock charge_weight replaces saturating_add with checked_add().unwrap() to satisfy the ForbidSaturatingMath custom lint

open-junius approved these changes Apr 14, 2026

View reviewed changes

evgeny-s reviewed Apr 16, 2026

View reviewed changes


		let caller = env.caller();

		let result = transactional::with_transaction(\|\| {


		env.charge_weight(weight)?;

		let (hotkey, amount, netuid): (T::AccountId, AlphaBalance, NetUid) =

Conversation

LandynDev commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issue(s)

Type of Change

Breaking Change

Checklist

Additional Notes

Uh oh!

open-junius commented Apr 3, 2026

Uh oh!

LandynDev commented Apr 3, 2026

Uh oh!

open-junius commented Apr 7, 2026

Uh oh!

LandynDev commented Apr 7, 2026

Uh oh!

LandynDev commented Apr 7, 2026

Uh oh!

open-junius left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

LandynDev commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

open-junius Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

LandynDev Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

open-junius Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

LandynDev Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

open-junius Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

LandynDev Apr 14, 2026

Choose a reason for hiding this comment

Uh oh!

open-junius left a comment

Choose a reason for hiding this comment

Uh oh!

evgeny-s left a comment

Choose a reason for hiding this comment

Uh oh!

evgeny-s Apr 16, 2026

Choose a reason for hiding this comment

Uh oh!

evgeny-s commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shamil-gadelshin commented Apr 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

LandynDev commented Apr 2, 2026 •

edited

Loading

LandynDev commented Apr 7, 2026 •

edited

Loading

evgeny-s commented Apr 16, 2026 •

edited

Loading