Smart-Contract-Owned P-Chain Staking Account

[Nuttymoon]

Motivation

Staking of AVAX to the Avalanche Primary Network happens on the P-Chain. This forces liquid staking providers to set up off-chain custodial MPC solutions to manage the bridging of AVAX from/to the C-Chain and the staking operations on the P-Chain.

The implementation of ACP-77 in the Etna upgrade (that went live on December 16th, 2024) has proven that it is possible to manage an L1 validator set from any Avalanche L1 by leveraging ICM (InterChain Messaging) to the P-Chain.

We propose to define a new type of P-Chain account that would be owned by a smart contract on an Avalanche L1 (most likely the C-Chain) and leverage ICM to manage AVAX staking operations on the P-Chain.

Description

This proposal requires (i) the creation of a new type of P-Chain account with its own AVAX balance and (ii) the introduction of new transactions to cover the entire staking workflow.

Smart-contract-owned P-Chain account

Similar to how a ValidatorManager contract is defined for each L1 and needed to sign L1-related transactions, a smart contract would be the sole capable of signing for staking operations for the AVAX tokens it owns. This type of account should be compatible with AVAX functions such as exports from the C/X-chain, P-Chain transfers, and validation/delegation outputs.

CreateStakingAccountTx

For the creation of such an account, we would introduce a new transaction to the P-Chain, e.g. CreateStakingAccountTx.

Staking account address

To remain compatible with existing P-Chain functions, we could envision following the same pattern as Bech32 X/P-Chain addresses but clearly identifying staking accounts by using 2 as the separator between the HRP from the address and error correction code (1 is currently used for EOAs). The four parts of a staking account Bech32 address would be:

• A human-readable part (HRP). On Mainnet this is avax.
• The number 2, which separates the HRP from the address and error correction code.
• A base-32 encoded string representing the 20-byte address.
• A 6-character base-32 encoded error correction code.

The 20-byte address could be obtained by hashing the ID of the transaction that created the staking account:

address = ripemd160(sha256(txID))

New P-Chain transactions

To cover the entire staking workflow, the following new transactions should be introduced:

• CreateStakingAccountTx as described above
  • Parameters: ChainID and Address of the smart contract owning the staking account
• ImportToStakingAccountTx, the equivalent of ImportTx for staking accounts (has to follow an export transaction on X/C-Chain)
• ExportFromStakingAccountTx, the equivalent of ExportTx for staking accounts
• AddValidatorForStakingAccountTx, the equivalent of AddValidatorTx for staking accounts
• AddDelegatorForStakingAccountTx, the equivalent of AddDelegatorTx for staking accounts

Any EOA can execute those transactions on the P-Chain as long as a proper ICM message signed by the C-Chain validators is passed as a parameter.

Use Cases

Trust-minimized liquid staking

Smart-contract-owned P-Chain accounts enable trust-minimized, decentralized liquid staking directly on Avalanche. These accounts allow smart contracts on the C-Chain to manage operations on the P-Chain simplifying the process while enhancing security and accessibility.

Smart contracts fully control all operations needed for liquid staking, including, but not limited to, staking, delegations, and cross-chain transfers, ensuring transparent and secure on-chain management.

DAO/institutional-owned nodes

DAOs and institutional actors could also operate smart-contract-owned P-Chain accounts, allowing risk-free yield on on-chain treasuries.

Open Questions

Should there be an emergency P-Chain account bound to the staking account?

Since anyone can relay messages, this shouldn’t be necessary and would increase trust assumptions.

Should there be the same output options for staking transactions?

AddValidatorTx and AddDelegatorTx have StakeOuts and RewardsOwner parameters. Not sure they make as much sense for staking accounts.

[MadGraph]

dope proposal there

[martineckardt]

Is there a way to abstract this from concrete P-Chain transactions
Types (e.g. ImportToStakingAccountTx, ...)? I was thinking about an Account Abstraction like setup where there are two transaction types:

CreateAbstractedAccountTx: Creates new account that is managed by an ChainID and Address combination

CallFromAbstractedAccountTc: Wraps any existing P-Chain transaction type and provides a signed warp adressedCall message over the parameters that authorizes the action

This way we would not only unlock staking, but all P-Chain tx types including creation of L1s. The entire P-Chain can be made accessible from any L1 and the C-Chain via a trustless relayer that can deliver these messages for a few (similar to ICM)

[Nuttymoon]

This is indeed another option that reduces implementation and maintenance cost and would be ideal.

Now that I think about it, ACP-77 comes with 2 types of messages for each operation: 1 signed by the L1 and 1 signed by the P-Chain (e.g. RegisterL1ValidatorMessage and L1ValidatorRegistrationMessage). But this is for operations that are not possible for regular P-Chain accounts.

[michaelkaplan13]

I think this a very cool idea, especially considering that liquid staking solutions already exist today and their off-chain components introduce potential security risks to the ecosystem since they could potentially secure a large amount of staked AVAX.

My main question for how it could all work is regarding how the new account addresses would work. For example, say I create an account using CreateStakingAccountTx, and then set that address as the owner of new UTXO created in a BaseTx. Were you thinking that:

• The BaseTx execution would be updated to identify the account address in the output, and not actually create a new UTXO but instead credit the AVAX to the account OR
• The BaseTx execution would be as exists today (create the new UTXO), and that the spending of the that UTXO in a future transaction would be authorized via ICM signature somehow?

A similar consideration would be how these addresses are handled when used as part of a multi-sig output.

Minor note: Using "1" as the separator after the HRP of a bech32 address is actually part of the official bech32 specification, so may want to consider altering the HRP prefix instead for display purposes such that all standard bech32 libraries/tooling would still work.

[michaelkaplan13]

Alternatively, I think an option could be to get rid of the notion of "addresses" for these accounts all together, such that they cannot receive any UTXOs, and treat them as a special case for holding AVAX (similar to how ACP-77 treats validationIDs).

For instance, in a IncreaseL1ValidatorBalanceTx, AVAX can be spent in inputs and credited to the specified validationID. No UTXO is actually created for the validationID (it almost appears to be "burned" in the tx), but it's owner can claim the AVAX balance in a future DisableL1ValidatorBalanceTx which creates a UTXO (which almost appears to be "minted" from no where).

[Nuttymoon]

Good point, I am not used to thinking in UTXO-based systems, and I didn't think about that problem at all. This is also why I started this as a discussion before drafting an actual ACP haha

I like the latter option, but wouldn't this imply introducing new transactions since it would not act as an actual account?

[michaelkaplan13]

I like the latter option, but wouldn't this imply introducing new transactions since it would not act as an actual account?

I actually view that option as closer to the notion of a proper "account", rather than creating a new address type that controls UTXOs and somehow is authenticated via ICM.

It would definitely require new transactions to define what interactions with the account are possible, similar to how IncreaseL1ValidatorBalanceTx and DisableL1ValidatorBalanceTx define what interactions are possible for the validation ID accounts (which hold AVAX balances).

With the goal of allowing for trust-minimized staking/delegation of AVAX from contracts on the C-Chain, those transactions could be something like the ones you defined:
ImportToStakingAccountTx, ExportFromStakingAccountTx, AddValidatorForStakingAccountTx, AddDelegatorForStakingAccountTx.

The only difference is the account doesn't have any P-Chain address; it is just identified implicitly by the (chainID,sourceAddress) tuple of the ICM message (so the accounts potentially don't even need to be explicitly created).

I haven't thought it through fully, but worth noting that either way this would require modifications to coreth (likely a new precompile on the C-Chain), because transactions that import AVAX on the P-Chain or C-Chain need to be atomic transactions and cannot use ICM.

The alternative route, as @martineckardt and @aaronbuchwald were mentioning, would be a new auth type for UTXOs on the P-Chain, which is essentially letting P-Chain UTXOs only be consumed via an ICM message from a specified (chainID,sourceAddress). Definitely agree this could be cleaner and more extensible, but the challenges I see there is that supporting this use case would still require new import/export transaction types (IIUC), and then the smart contracts would also need some mechanism of knowing and choosing which UTXOs they control and would like to spend on the P-Chain.

[aaronbuchwald]

Love this. I'd be in favor of abstracting this as @martineckardt suggested towards a new auth type for existing P-Chain transactions rather than creating duplicates of existing transaction types.

Wrote up my thoughts on warp addressed transactions here:

• Onchain Transaction Generation
• A Step Towards Subnet Sovereignty