Also, there is a much bigger elephant in the room for power users - signing with MPC. And even bigger elephant in the room - signing with MPC using SputnikDAO proposal. Imagine you have a critical contract under management (intents.near), and you want to be able to upgrade it in the future. Your first option is to have the full access key to the intents.near account and store it securely, so you can sign a DEPLOY_CONTRACT transaction in the future - nice, but really scary - you lose the key and your contract won't ever be upgraded. Second option is to implement the function inside the contract that will allow attaching the new code and initiate DEPLOY_CONTRACT from the contract itself. But if you ever deploy a broken contract or the contract without the upgrade method, you are out of luck. And here we come to the third option, follow me: Note: With NEAR MPC you can sing any payload (including NEAR transaction) and the key is derived uniquely for the NEAR account. So let's create a SputnikDAO contract and generate a new public key on NEAR MPC derived for the SputnikDAO account id (e.g. devhub.sputnik-dao.near), and add that key as the full access key to my contract (intents.near). Now, I can prepare a transaction (e.g. with DEPLOY_CONTRACT action) with a signer account id set as intents.near and submit a DAO proposal to my DAO (devhub.sputnik-dao.near) to call MPC to sign the prepared transaction hash. Once the proposal is voted for, it will make an on-chain call to MPC and will get the signature. NEAR CLI then combines the unsigned transaction with the signature and submit that signed transaction to the chain! Isn't it clever? Thanks to @ilblackdragon for pitching that idea and github.com/vsavchyn-dev for implementing it! Did you follow it till the end? Congrats, you now have a degree in NEAR Accounts Model and Chain Abstraction!