feat: add NeuronRegistrationBurn event for tracking alpha burned

[DanielDerefaka]

Summary

Adds a new event NeuronRegistrationBurn that is emitted during burned registration to enable accurate tracking of the alpha amount that was burned.

Problem

Currently, it's impossible to calculate how much alpha was burned by neuron registration (as noted in #2104). This makes accurate balance bookkeeping and analytics difficult.

Solution

Added a new event NeuronRegistrationBurn(NetUid, T::AccountId, TaoCurrency, AlphaCurrency) that includes:

• netuid: The subnet where registration occurred
• hotkey: The registered hotkey
• tao_cost: The TAO amount that was spent
• alpha_burned: The alpha amount that was actually burned

The event is emitted alongside the existing NeuronRegistered event during do_burned_registration.

Changes

• pallets/subtensor/src/macros/events.rs: Added new NeuronRegistrationBurn event definition
• pallets/subtensor/src/subnets/registration.rs: Emit the new event with burn amounts

Test plan

• Verified cargo check --lib passes
• Verified cargo check --tests passes
• Event emission logic follows existing patterns

Fixes #2104

Contribution by Gittensor, see my contribution statistics at https://gittensor.io/miners/details?githubId=101010297

[DanielDerefaka]

@open-junius would you review this PR?

[open-junius]

@open-junius would you review this PR?
Please set the target branch as devnet-ready. and bump the runtime version.

[DanielDerefaka]

@open-junius Updated I've expanded the existing NeuronRegistered event to include tao_cost and alpha_burned:

NeuronRegistered(NetUid, u16, T::AccountId, TaoCurrency, AlphaCurrency)

For POW and root registration (which don't burn), the values are set to 0.

[DanielDerefaka]

@open-junius The PR is now targeting devnet-ready and the runtime spec_version has been bumped (365 → 366). Ready for review

[DanielDerefaka]

@open-junius Just checking on the review? if anything needs adjusting.

[DanielDerefaka]

@open-junius I've pushed a fix addressing the CI failures:

Changes in commit 6d0d9d3:

1. cargo fmt - Reformatted deposit_event call in registration.rs to pass formatting check
2. cargo audit - Added RUSTSEC-2025-0137 (ruint unsoundness) to the ignore list - this is a transitive dependency from polkadot-sdk

Let me know if anything else needs adjustment

[open-junius]

@open-junius I've pushed a fix addressing the CI failures:

Changes in commit 6d0d9d3:

1. cargo fmt - Reformatted deposit_event call in registration.rs to pass formatting check
2. cargo audit - Added RUSTSEC-2025-0137 (ruint unsoundness) to the ignore list - this is a transitive dependency from polkadot-sdk

Let me know if anything else needs adjustment

Thanks! Let me run CI again.

[DanielDerefaka]

@open-junius Just following up CI is now passing (cargo fmt, cargo audit, all tests). The only failing check is check testnet which appears to be an infrastructure issue (HTTP 503 from the archive node), not related to my code changes.

Happy to make any additional changes if needed. Thanks for your time

[bdmason]

@DanielDerefaka this code (existing before your PR) is very misleading:

 // Tokens are swapped and then burned.
        let burned_alpha = Self::swap_tao_for_alpha(
            netuid,
            actual_burn_amount,
            T::SwapInterface::max_price(),
            false,
        )?
        .amount_paid_out;
        SubnetAlphaOut::<T>::mutate(netuid, |total| {
            *total = total.saturating_sub(burned_alpha.into())
        });

Alpha is not being burned here despite the variable name. When alpha is burned the user's balance is decremented but SubnetAlphaOut is not, when alpha is being recycled SubnetAlphaOut is decremented along with the balance.

It looks like you didn't go with a new event with burn in the name and extended the old one, so I don't think it has any meaningful effect on the PR.

The existing variable names should probably be cleaned up though.

[DanielDerefaka]

@bdmason good catch, yeah the naming is confusing. when SubnetAlphaOut gets decremented thats recycling back to the reserve, not burning. burning would just reduce the user balance without touching the pool.

since i went with extending the existing event it doesnt really change anything for this PR but the var names are definitely misleading

want me to rename burned_alpha -> recycled_alpha as part of this PR? or keep it separate so this stays focused on the event change?

[bdmason]

@DanielDerefaka I'd do the name change in this PR else you'll get merge conflicts to deal with

[bdmason]

Might also be worth checking with @sam0x17 @gregzaitsev @camfairchild @open-junius to see if the intention really was to burn the alpha instead of recycling it. If the intention is to burn then don't rename anything and it should be a separate PR as it's a bit less trivial then.

[open-junius]

Might also be worth checking with @sam0x17 @gregzaitsev @camfairchild @open-junius to see if the intention really was to burn the alpha instead of recycling it. If the intention is to burn then don't rename anything and it should be a separate PR as it's a bit less trivial then.

According to the called function, these token is added into recycled storage. The term burn and recycle are mix used.

[camfairchild]

This should just be a generic recycle* event, imo. Not specific to the registration