Recycle fees via chain ext with immutable custodial fallback#48
Draft
Recycle fees via chain ext with immutable custodial fallback#48
Conversation
recycle_fees() now calls the subtensor AddStakeRecycleV1 chain extension (func_id 18) to atomically stake and recycle fees on-chain instead of transferring TAO to an external wallet. Adds SubtensorExtension trait with CustomEnvironment for ink! chain extension support. Requires subtensor chain extension func_ids 16-19.
Chain extension handles fee recycling on-chain now, so recycle_address storage, setter, getter, and CLI command are dead code. Also adds pre-check for zero fees and a hint when ContractReverted occurs.
Probe-and-latch: recycle_fees tries the chain extension on every call. On success it permanently latches chain_ext_enabled=true and stops falling back. Until then, a chain-ext failure transfers fees to the immutable recycle_address set at construction (no setter, no owner override). Once latched, the custodial path is dead forever. Also makes recycle_fees permissionless — anyone can trigger it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Alternative to #9
Same chain-ext call, plus an immutable custodial fallback so a signature mismatch
or slipped subtensor rollout can't trap fees in the contract.
How it works
recycle_feesis permissionlessadd_stake_recyclefirst (the chain extension, that doesn't exist today)chain_ext_enabled = true. Permanently after that, chain ext is the only path of recycling.env.transfer(recycle_address, fees)-> custodial wallet transferrecycle_addressis set in the constructor — no setter, nobody can change itChainExtensionLatchedonce when the flip happensFeesRecycled { via_chain_ext }on every recycleWhy implement it like this?
The subtensor chain extension is still weeks out, probably 30th at earliest before it hits mainnet.
We don't want to sit on our hands waiting for it to ship. This lets us deploy now with the custodial wallet actually wired up, and the moment the chain extension lands on mainnet, the first
recycle_feescall after that flips us over to it automatically and permanently.No contract upgrade, redeploy, or admin action.
By rolling something like this out early, we'd still be pinned to the requirement
function_id = 18add_stake_recycle(hotkey, netuid, amount)If for some reason the mainnet deployment differs from these mappings then a redeployment of the contract would be necessary since its non upgradeable. This is worth a check/ask with subtensor team maybe
Follow-ups (not in this draft)
recycle_addressagain — CLI deploy + admin need updatingmetadata/allways_swap_manager.json