SIMD-0089

TL;DR

This proposal suggests replacing the non-existent native program at address `Feature111111111111111111111111111111111111` with a Core BPF Program, as described in [SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88). Feature accounts are already assigned the owner program address `Feature111111111111111111111111111111111111`. Deploying a Core BPF program at this address would provide engineers with the capability to revoke pending feature activations. **Note:** The process by which core contributors *activate* features would remain completely unchanged.

Summary

This proposal suggests replacing the non-existent native program at address `Feature111111111111111111111111111111111111` with a Core BPF Program, as described in [SIMD 0088](https://github.com/solana-foundation/solana-improvement-documents/pull/88). Feature accounts are already assigned the owner program address `Feature111111111111111111111111111111111111`. Deploying a Core BPF program at this address would provide engineers with the capability to revoke pending feature activations. **Note:** The process by which core contributors *activate* features would remain completely unchanged.

Motivation

Currently, a feature is queued for activation by a keypair holder creating an empty account and assigning it to the `Feature111111111111111111111111111111111111` program. Because there is no actual program implementation at this address, the queuing is irreversible; if the runtime knows about a feature gate at some address, it will activate it at the next epoch boundary. This means there is no recourse in the case of a mistaken queuing, discovery of a bug, or simply a desire to manage the cadence and schedule of activations. A fully-implemented Core BPF program would take ownership of those accounts and support revoking queued features, giving engineers more flexibility and safeguards.

Key Changes

• Feature Gate program: The Core BPF program that all feature accounts will be assigned to, with address Feature111111111111111111111111111111111111.

Impact

Core contributors are positively impacted by this change, since the ability to revoke pending feature activations is a significant security advantage. There is otherwise no change to the activation process whatsoever. This includes queuing features for activation with the CLI and the timing of their activation by the runtime.

Backwards Compatibility

This change is 100% backwards compatible with the existing feature activation process. It *only* adds the ability to revoke pending activations.

Security Considerations

Currently the accounts used for feature-gating are owned by a program ID that does not have any implementation. This means that there is no on-chain authority that can modify feature accounts once they've been created under `Feature111111111111111111111111111111111111`. This allows the runtime to confidently update their state upon activation. With this proposal, a live BPF program - which can accept instructions from anyone and execute code - will be the owner of these accounts. This introduces new risks that must be mitigated through careful implementation of Feature Gate program functionality.