The main difference between staking from a smart contract wallet (like this one) and staking from an externally owned account is that a smart contract wallet does not have a key to sign the staking transaction. Thus, special procedures must be created to reconcile this difference if we are to support staking from ONE wallet.

To give the reader some background context, let us first examine the status quo procedure to validate a staking request from a private-key based wallet (i.e. externally owned account, or EOA). This is documented briefly in Harmony documentation. Here is a more elaborated description:

1. first, the EOA wallet signs a staking transaction and sends an RPC request under hmy_sendrawstakingtransaction carrying a StakingTransaction.
2. The node receiving the RPC request would invoke the RPC's handler, which performs a series of operations and eventually validates the transaction before adding it to a transaction pool
3. During the validation in (2), the sender's signature is verified using the standard ECDSA algorithm based on the signature (r, s, v values) provided by the EOA wallet within the transaction. See 1, 2, 3, 4, and eventually 5.

Since smart contract wallets cannot keep the private key for ECDSA, it generally cannot produce ECDSA signatures unless the signing is deferred to a client which has the private key and would request approval from the user to sign. Nonetheless, the signature produced by the client would be a signature for the client's EOA wallet's address, which is not valid for the smart contract wallet's address. However, a more fundamental issue is that ONE Wallet does not have private key at the client side at all, nor uses private key anywhere (aside from being part of the composable authentication scheme in the future, which is not yet implemented and should be considered as an advanced security feature). Therefore, it is not possible to use the same procedure under RPC hmy_sendrawstakingtransaction to implement staking from ONE Wallet.

I see two three approaches to solve to this problem.

1. Create a standard staking smart contract and a pool service protocol. Based on the contract and the protocol, establish multiple staking pools that offers staking as an on-chain service. Each staking pool would manage its own EOA wallets that aggregates the staked ONEs, and perform the actual using pre-existing RPC call (hmy_sendrawstakingtransaction) and the status quo procedure. Obviously, this approach relies on the honesty and security of the pools. If a pool is hacked, or becomes malicious and runs away with the staked ONEs, all users who staked their funds to that pool would lose their funds.

2. Modify the EVM code and add a special function to the smart contract that allows staking as a native function call. The signature validation should be performed by calling isValidSignature function on the contract, per EIP-1271 . This approach is much more secure, but the implementation can be complex. I am not familiar with that part of the code so at this time I only know it would not be as simple as adding a precompiled contract, since this native function would call non-native function to validate the signature, and would have side effects (changing balance of the contract). This approach also requires all validators to upgrade to a new version of Harmony node once the implementation is done.

3. See the comment below Support staking on Harmony from ONE Wallet #9 (comment)