We need to talk about how we manage Full Access Keys for smart contract accounts on
@NEARProtocol
If you run a critical account like intents.near, your upgrade path usually comes down to two uncomfortable choices. You either keep a Full Access Key sitting on someone’s hardware wallet, which is just a human-shaped single point of failure, or build custom upgrade logic into the contract and pray a bad state migration never bricks it.
The fix isn't hiding the seed phrase better.
@Freol wrote about a clean setup for this a while ago using SputnikDAO and NEAR MPC.
Instead of a single person holding a god key, an MPC public key is derived for the DAO account and attached as a Full Access Key to the contract account.
When you need to push a patch:
✦ Generate the raw, unsigned DeployContract transaction payload for the contract account
✦ Request the multisig to sign the transaction with MPC
✦ If the multisig proposal is approved by the voting members, the multisig calls the MPC contract to sign it
✦ NEAR CLI combines the unsigned transaction with the resulting signature and submits it to the network
The full private key never exists in one place, and no one holds it.
Governance approves. MPC signs. The network executes.