# Mission 9 — Safe Mode and Multisignatures > Protect important Vaulta transactions with a waiting period, learn how MSIG proposals work, and prepare to respond if an active key is compromised. Canonical: https://help.blockzhub.io/articles/mission-9-safe-mode-and-multisignatures [In earlier missions](https://help.blockzhub.io/categories/blocksfinity-onboarding), you learned the difference between your owner and active permissions, how to back up your keys, and how to recover access. Now we will add Safe Mode to protect selected transactions from being executed immediately with your everyday active permission. In this mission you will enable Safe Mode, send a tiny delayed $A transfer, protect an additional token, create a multisignature (MSIG) proposal manually, and learn the emergency recovery and deactivation procedures. We use a 5-minute (300-second) waiting period only so you can finish this practice mission. For an account intended to hold substantial value, plan for at least 24 hours (1,440 minutes / 86,400 seconds) instead. An alert is useful only when you have enough time to notice it, reach your protected owner credential, and respond. Even 24 hours is not a guarantee: alerts can be missed, and an attacker may exploit permissions or contracts that you did not protect. The screenshots use supportacc1h for Safe Mode and supportacc1a for the separate manual MSIG demonstration. Perform transactions only with accounts you own or have permission to use. Start with a low-value training account. ## What is Safe Mode, and why would I use it? Normally, one authorized active key or passkey can sign an everyday transfer immediately. If that credential is stolen, the attacker may be able to move liquid tokens before you even see a notification alert. Safe Mode changes the authorization for selected smart contracts. Instead of executing a protected active action immediately, Blocksfinity helps you create and approve an MSIG proposal. The action is then executable only after the required waiting period. Prepare a protected $A transfer | v Create and approve an MSIG proposal | v Wait period (for practice only 5 minutes) | v Execute the approved proposal | v Verify the actual $A transfer on VaultaThis waiting period gives you a chance to recognize an unauthorized proposal and take protective action before the transfer executes. ### How does one signer plus a waiting period work? Remember that Vaulta permissions have a threshold and that each authorized key, account, or waiting period has a weight. In this mission, your ordinary active permission can be satisfied by one of its authorized credentials. Safe Mode introduces another permission: active permission - threshold 1 an active key or passkey weight 1 safemode permission - threshold 2 youraccount@active weight 1 wait 300 (or more) seconds weight 1 -------- combined authorization weight 2The wait is not a signature and not another person. It is an on-chain time condition. Blocksfinity uses the eosio.msig smart contract to manage proposals and approvals while that condition is being satisfied. Later we will also inspect an account where approvals can be supplied by different accounts. Key idea: Safe Mode uses the blockchain's actual permission rules. It does not merely add a countdown inside a website. ### What is protected - and what is not? When you enable the illustrated Safe Mode setup, Blocksfinity links these three contracts to the new safemode permission: - eosio: important system and resource actions. - core.vaulta: actions on the $A token contract. - eosio.token: actions on the $EOS token contract. Other token contracts are not automatically protected. We will add token.rms, the contract behind the $V token, later in the mission. Your powerful owner authority can still authorize changes immediatly and is deliberately kept available for recovery. Enabling Safe Mode also uses eosio::limitauthchg to restrict changes to account permissions to owner. This matters because a stolen active key must not be able to simply remove the Safe Mode links or rewrite the protective permission. We will inspect this action during activation and see how it is cleared when Safe Mode is disabled. Security warning: Safe Mode does not guarantee protection from every malicious smart contract action, a stolen owner key, or an already completed transfer. Monitor alerts, check your effective permission links, and maintain a separate recovery method. ## Part 1 - Check recovery before changing security settings ### Step 1 - Confirm that you have an independent recovery path Open [Wallet -> Security](https://www.blocksfinity.com/wallet/security) and find Recover readiness. The checklist helps you confirm that you can find your owner recovery key and have practiced recovery. A passkey or an active key on the same device is not a substitute for independent owner recovery. If you cannot locate a separate owner recovery method, stop and repeat [Missions 7 and 8](https://help.blockzhub.io/categories/blocksfinity-onboarding) before proceeding. ### Step 2 - Practice the recovery procedure Click Practice Recover, enter your own account name, and select Continue. Practice mode is intended to help you understand the paths available when your browser, Authenticator, or everyday credentials are unavailable. The recovery screen offers a way to connect another wallet that controls your account or check the owner recovery key against the public key on-chain. Use whichever method you have genuinely prepared. In the illustrated wallet recovery path, a successful connection returns you to the account under @owner. Notice the links to Keys & Permissions, the security checklist, and your account. A recovery test should leave you able to inspect and control the actual on-chain account, not just display a success message. Return to Recover readiness, acknowledge the steps you completed, and confirm the ready state. Checkpoint: You know where the protected owner credential is, how to use it on a trusted device, and how you would regain control if the active credential or device disappeared. Never send your private key or master password to anyone. ## Part 2 - Enable Safe Mode with owner ### Step 3 - Look at the account's current permissions Open your account in Blocksfinity Explorer and go to [Account](https://www.blocksfinity.com/account) -> Chain Data -> Keys. Before activation, note which keys or passkeys satisfy owner and active. In our example, active contains a normal public key and a passkey, while owner is a separate keypair. This gives you a before-and-after comparison. Your account, keys, and permissions exist on Vaulta, not inside Blocksfinity. ### Step 4 - Open Safe Mode as owner Sign in as youraccount@owner and go to [Wallet -> Security](https://www.blocksfinity.com/wallet/security). The example screenshot shows supportacc1h@owner and Safe Mode marked DISABLED. Read the page's short explanation: owner can still act immediately, while active signs a delayed proposal. Owner-key precaution: This illustrated Authenticator flow requires signing with owner. Importing an offline owner private key into an internet-connected device increases risk. Use a training account here. Before keeping substantial funds in the account, consider rotating to a newly generated, offline-only owner key as taught in [Mission 7](https://help.blockzhub.io/articles/mission-7-backup-recover-and-ensure-separate-permission-keys), after securely backing it up and verifying access. Never reuse the same key for both owner and active. ### Step 5 - Set five minutes for practice Under Waiting period (minutes), enter 5. The page translates this into 300 seconds. Click Enable Safe Mode. For a production account containing significant liquid assets, consider at least 24 hours instead. Five minutes makes this exercise convenient, but normally provides too little time to sleep, travel, receive alerts, retrieve an offline key, and respond. ### Step 6 - Read and confirm the warning Blocksfinity explains that the active permission can no longer sign the protected system or token actions immediately. It will schedule them instead. Owner-authorized actions and permission changes still work immediately. Confirm Enable Safe Mode only if you understand this trade-off. ### Step 7 - Open Authenticator and select owner The signing window offers the Blocksfinity Authenticator app, a QR-based mobile path, or signing in the browser. Use your intended Authenticator method. In this example we open the Authenticator app. Check that the signing account is youraccount@owner. The Authenticator warns that this transaction changes account permissions. That warning is correct: you are editing the network's authorization rules, not just an app setting. ### Step 8 - Inspect every action before signing The first important action is eosio::updateauth. It creates or updates an on-chain permission. Confirm that it creates safemode with owner as its parent and threshold 2. Further down, confirm that youraccount@active contributes weight 1, and the 300-second wait contributes another weight 1. Together they satisfy the threshold of 2, but only after the waiting period. Next are eosio::linkauth actions. Link Auth tells Vaulta which permission is required for actions on a contract. Check that eosio and core.vaulta are linked to safemode. Check the link for eosio.token as well. A whole-contract link shown without a specific action covers actions on that contract unless an existing, more specific action-level link takes precedence. Finally, look at eosio::limitauthchg. In this activation request, Allow_perms contains owner, restricting actions that change authorizations (updateauth, deleteauth, linkauth, unlinkauth) to owner authority. This is an essential part of the protection: active should not be able to remove the restrictions that it is subject to. The Authenticator labels this action's format as unverified, so check its account and fields especially carefully. Mark the review checkbox and select Sign only after inspecting all six actions. ### Step 9 - Check the successful activation on-chain The success screen now states that an action with Safe Mode enabled waits 5 minutes (300 seconds). It also lists the three built-in protected contracts and offers a field for adding another contract. Save the transaction ID if you want to inspect this permission change later. Return to [Account](https://www.blocksfinity.com/account) -> Chain Data -> Keys. You should see the new safemode permission, its active contribution, 300 seconds, and links to eosio, core.vaulta, and eosio.token. Checkpoint: Do not continue merely because the website reported success. Confirm that the on-chain permission, threshold, waiting period, and contract links match what you intended. ## Part 3 - Enable account alerts and check RAM ### Step 10 - Open account alerts Click Alerts at the top of Blocksfinity or open [Blocksfinity Alerts](https://www.blocksfinity.com/alerts). In the example, email notifications are being configured for supportacc1h. Enter the account and an email address you actually monitor, then choose Get Alerts. ### Step 11 - Prove account ownership The screenshot shows a Blocksfinity Authenticator request for msigvote.stp::prove, used by the illustrated flow to prove control of the account. This is not a token transfer. Check that you are proving ownership for the correct account and that the request contains no unexpected actions; then sign. After the ownership proof is accepted, the Authenticator displays a signed result and transaction ID. Close the window and return to Alerts. ### Step 12 - Choose which events should notify you Your alert preferences should now show a connected destination. Other channels, such as Telegram, may also be offered. The in-app Alert inbox lets you review recent notifications. Under Alert types, enable at least Multisig (propose / approve / exec), Keys & permissions, and Transfers. Click Save alert types. You can enable other categories too if they are useful to you. Important: Alerts are notifications, not an on-chain veto. An email, phone, or messaging app may be offline or delayed. The safety margin is the time you actually have available to respond before execution. ### Step 13 - Check that you have enough RAM MSIG proposals occupy blockchain storage. For this exercise, check that the account has approximately 1,000 spare RAM bytes as a practical reserve; this is not a fixed protocol requirement for every transaction. If you need more, open [Wallet -> RAM](https://www.blocksfinity.com/wallet/ram), select Bytes, and enter 1000 for the receiving account. Check Payer, Receiver, and Bytes in the confirmation before selecting OK. Buying RAM costs tokens and changes on-chain resource allocation. Some resource actions also fall under Safe Mode. If your account cannot complete a top-up immediately, use a properly authorized separate account or owner-controlled route rather than assuming active can bypass the delay. ## Part 4 - Send your first Safe Mode-protected $A transaction For everyday use, sign out of @owner and sign in as youraccount@active. This exercise should not require you to use the more powerful owner key again until you manage permissions or perform recovery. ### Step 14 - Prepare a very small transfer Open [Wallet -> Transfer](https://www.blocksfinity.com/wallet/transfer) and enter an account you control as recipient. Send a tiny amount such as 0.0001 $A and leave the memo blank. The screenshot uses supportacc1c as recipient. Click Transfer. ### Step 15 - Review the transfer confirmation Verify Token contract: core.vaulta, the receiving account, and the amount. Press Submit only when these values are correct. ### Step 16 - Schedule instead of transferring immediately Blocksfinity detects that this action is protected by safemode and asks Schedule delayed send? It explains that the MSIG proposal cannot execute for five minutes. Select Schedule send. What happened technically? You have not sent the money. You are asking Vaulta to store a proposed transfer with an authorization requirement that needs the wait. ### Step 17 - Open Authenticator with active Open Blocksfinity Authenticator when prompted. The same wallet options are shown again. This time, confirm that you are signing as youraccount@active, not owner. ### Step 18 - Understand the proposed transaction You should see eosio.msig::propose. This action stores the proposal under a proposer name and unique proposal name and lists which account permissions have been asked to approve it. Note the proposal name so you can find it later. Inside that proposal is the actual core.vaulta::transfer. Inspect the from account, recipient, amount, and authorization youraccount@safemode. The transaction also shows delay_sec: 300. The wait belongs to the proposed transaction's authorization, not to the propose button itself. ### Step 19 - Approve the proposal with your active credential The second MSIG action is eosio.msig::approve. It records approval of the proposal from youraccount@active. Check the proposer, proposal name, and approving level. Then confirm you reviewed every action and select Sign. Blocksfinity confirms that the proposal was scheduled and can be executed from MSIGs after five minutes. This success message means the proposal and approval were submitted, not that the $A transfer has happened. Check whether a matching alert arrived. ## Part 5 - Inspect, execute, and verify your MSIG ### Step 20 - Find your open proposal Open [Blocksfinity MSIGs](https://www.blocksfinity.com/msigs). Choose Open, find your proposer and proposal name, and open the details. You can filter or search by proposal name if necessary. ### Step 21 - Read the timing and approval status The proposal details show Status, Expiration time, Approvals, and buttons such as Unapprove, Execute, and Cancel. While it says Waiting for delay, execution is unavailable. Notice that Expiration time is not the waiting period. Expiration is the deadline after which the proposal cannot be executed. The separate Executable after time tells you when the five-minute restriction is satisfied. Under Signer eligibility, you can see the effective permission calculation. For this Safe Mode proposal, the active approval contributes one weight and the time delay contributes the other. The display can show 1 / 1 requested signer approved even though the safemode threshold is 2. This is not two people signing. ### Step 22 - Inspect the proposed action and the optional signals Under Action & data, confirm that the inner action is core.vaulta::transfer, its authorization is youraccount@safemode, and the recipient and amount match the transfer you intended. Requested approvals should show your @active approval. The MSIG page also offers For / Against signer signals with optional reasons. These are advisory comments, not the cryptographic approvals. An Against signal does not stop a proposal that is otherwise authorized. This is useful if more than one signer is requested and some of the signer want to inform others why they support or are against a certain MSIG proposal. For our example we can ignore it. ### Step 23 - Execute after the waiting period After the wait, when the proposal shows Ready to execute, recheck its contents and select Execute. Open Authenticator using the shown option. Review eosio.msig::exec and its proposer, proposal name, and executer. The illustrated request also includes core.vaulta::noop as a CPU/NET-cover action. It is not the token transfer; still review it like every other action. Sign only the intended execution request. Anyone who can properly authorize an exec call can trigger an already-approved, ready proposal. It does not require a second approval from the original signer. Execution is a separate on-chain step, and you should verify that the underlying transaction actually completed afterward. ### Step 24 - Verify the resulting transaction and alerts The success notice gives you a transaction ID for the execution request. Save it if you want to inspect the receipt. Open [Alerts](https://www.blocksfinity.com/alerts) and compare the notices for proposal creation, approval, and execution. Notifications help you recognize activity but are not proof that the final transfer succeeded. You also should have received those alerts on your email. Finally, open the account's Transaction history and verify the sequence: propose -> approve -> execute -> transfer. Confirm the tiny amount also arrived in the recipient account. Checkpoint: You can now explain the difference between a successfully created MSIG proposal and a successfully executed token transfer. ## Part 6 - Add another token contract to Safe Mode ### Step 25 - Identify the smart contract behind a token In your account's Tokens list, you may have a token other than $A or $EOS. The example account also holds $V. Open the [$V token page](https://www.blocksfinity.com/tokens/token.rms/V). Its token contract is token.rms. A token from another contract is not automatically protected merely because Safe Mode already protects $A and $EOS. ### Step 26 - Link the token contract to safemode Sign back in with youraccount@owner. Open [Wallet -> Keys & Permissions](https://www.blocksfinity.com/wallet/permissions) and choose Link Auth. Configure: - Change permission: safemode - Contract name: token.rms - Contract action: All actions (whole contract) Then choose Link auth. ### Step 27 - Understand the whole-contract warning The confirmation asks Link every action on this contract? Approving this means every action of token.rms, including actions added by the developer later, will require safemode, unless a more specific action-level link already applies. This is useful when you want to protect the token contract broadly, but it can also delay other functions of that contract. ### Step 28 - Sign the permission link with owner Open Authenticator using your configured signing method. Inspect the eosio::linkauth action. The Code must be token.rms, the Requirement must be safemode, and the signing authority must be owner. The screenshot also shows an optional core.vaulta::noop resource-cover action. Select Sign after verifying the whole request. ### Step 29 - Verify protection for token.rms After the transaction succeeds, save its transaction ID if you wish. Return to [Account](https://www.blocksfinity.com/account) -> Chain Data -> Keys. You should now see token.rms alongside eosio, core.vaulta, and eosio.token under the safemode permission. Important: Whole-contract links do not necessarily override more specific action-level links. Before relying on Safe Mode for any token, inspect the effective on-chain links for the actions you actually want to protect. ### Why do we not link eosio.msig smart contract to safemode? eosio.msig is the contract that creates (propose), approves (approve), withdraws approvals (unapprove), executes (exec), and cancels (cancel) proposals. We want to delay the protected action inside the proposal, not make the management of that proposal wait as well. If eosio.msig were linked to Safe Mode, you could obstruct proposal creation, execution, or urgent unapproval and create a confusing chain of delayed proposals. So, we do not want to link eosio.msig to safemode for our safemode configuration. ## Part 7 - Create a multisignature proposal manually Until now, Blocksfinity created the MSIG proposal automatically when you tried a protected safemode action, like for example an $A transfer. Let's see how a proposal can be created manually for an account that uses several authorization methods. A proposer submits a transaction for review. The requested approvers decide whether to approve. The executer submits execution once the required authority and timing conditions are met. These can be different accounts. Anyone may propose a transaction (or execute an approved proposal), but proposing does not grant permission to spend another account's funds. ### Step 30 - Understand the example account's authority [Open the example](https://www.blocksfinity.com/account/info/supportacc1a) supportacc1a and inspect Account -> Chain Data -> Keys. Its active permission has threshold 2, with supportacc1b@active and supportacc1c@active each contributing weight 1. That means the two accounts together are one way to reach threshold 2. But look carefully: this example also has a public key with weight 2 and a 120-second wait with weight 1. So it is not a pure 'two people must always sign' setup. Depending on the request and its delay, a different valid combination could satisfy the threshold. A strict company treasury requiring two independent people would need a permission that does not include a weight-2 single key or an alternate one-signature-plus-wait route. ### Step 31 - Start a manual proposal Open [Blocksfinity MSIGs](https://www.blocksfinity.com/msigs) and select Create. ### Step 32 - Choose the proposer, name, expiration, and delay Enter a unique Proposal name, select the Proposer name, and choose an Expiration time far enough away for the intended signers to respond. The example is proposed by supportacc1h and uses an Execution delay of 300 seconds. Select Continue. Expiration tells you when the proposal stops being usable. Execution delay tells Vaulta how long the underlying transaction must wait; these are different fields. ### Step 33 - Add a transfer as the proposed action Choose + Add more transaction. Select Transfer token from the list of available action templates. The added Transfer token section can now be expanded to enter its details. In the demonstration, enter a tiny transfer of 0.0001 $A from supportacc1a to supportacc1h. The underlying transaction uses the authorization supportacc1a@active, matching this example account's permission setup. If you are practicing with your own Safe Mode-protected account, the protected core.vaulta transfer must instead use the correct youraccount@safemode authorization and an adequate delay. Do not copy the example's permission blindly. ### Step 34 - Request approval from the appropriate accounts The demonstration requests approvals from supportacc1b@active and supportacc1c@active, which can contribute one weight each. Add the correct accounts and permissions, then click Continue. Those accounts must control their own signing credentials to approve. Requesting their signatures does not create those signatures. Do not submit a proposal involving other people's assets without their agreement. ### Step 35 - Review and sign the proposal as proposer Check the Proposal name, Proposer, Execution delay, Expiration time, Requested approvals, token contract, transfer amount, sender, recipient, and inner authorization. If everything is correct, select Propose and sign. Open Authenticator when requested. Review the eosio.msig::propose request. Inspect its proposed transaction, including delay_sec: 300 and its inner core.vaulta::transfer. Sign as the proposer. This signature creates the proposal; it does not count as an approval from supportacc1b or supportacc1c. ### Step 36 - Confirm creation and find the new MSIG Blocksfinity confirms Proposal created. Approve and execute it from the proposal that just opened. The underlying transfer has not occurred. The proposing account's transaction history records the eosio.msig::propose action. This is evidence that a proposal was created, not evidence that funds changed hands. Return to [MSIGs](https://www.blocksfinity.com/msigs) -> Open and find the new proposal. Its pending approval count reflects the fact that the requested signers have not yet approved. ### Step 37 - Read the proposal as a signer would Open the proposal detail view. It shows the proposal status, expiration, requested approvals, and possible Approve, Execute, and Cancel actions. Do not approve a proposal solely because its proposer is familiar. Under Signer eligibility, inspect the actual permission threshold, eligible signers, and their weights. The screenshot reports that one weight can come from the proposed transaction's time delay, while the requested accounts have not approved yet. Again, the number of requested approvers is not always the same as the minimum number of human signatures that the whole permission could accept. The For / Against signals area is for comments or preferences by requested signers. Those signals are advisory and do not prevent execution when cryptographic authorization requirements are satisfied. Finally, check Action & data and Requested approvals. In the example, the proposal would transfer 0.0001 $A from supportacc1a to supportacc1h, with requests for supportacc1b@active and supportacc1c@active. Your practice: Create a proposal for an account you control, or coordinate the supportacc1a demonstration with its authorized signers. An eligible signer should review the inner action before selecting Approve. When enough effective weight is available and the delay has elapsed, the proposal may be executed; verify the actual result in Explorer. Never treat a proposal or an alert as proof that the intended transaction already happened. ## Part 8 - Emergency: your active key may be stolen Safe Mode is most useful when you can react during the waiting period. The following screenshots show how Blocksfinity helps you replace compromised active authorization and void previously recorded MSIG approvals. This is a recovery procedure, not something to perform casually on an account that you still use normally. ### Step 38 - Find the emergency action Sign in with a separately protected owner credential and open [Wallet -> Security](https://www.blocksfinity.com/wallet/security). Find Emergency: active key stolen and Replace active key and void approvals. The screen also shows the separate Disable Safe Mode button, which we will examine in the next section. If you receive a suspicious MSIG alert, review the inner transaction, then begin emergency recovery promptly. Do not wait until the five-minute or 24-hour delay expires. ### Step 39 - Prepare a completely new active key First [generate a new, unique keypair](https://www.blocksfinity.com/wallet/permissions) by a method you trust. Securely back up the new private key; enter only its public key into the New active public key field. Do not paste a private key, reuse the compromised key, or use your offline owner key as the everyday active key. Click Replace active key and void approvals. ### Step 40 - Understand the destructive confirmation The confirmation warns that this process wipes every key currently on active and replaces them with the one new public key. Existing active passkeys will therefore stop authorizing the account and may need to be registered again. Owner is not being replaced in this procedure. Only proceed if you have backed up the new key, know how to sign using it, and still control the separate owner authority. Confirm Replace active key and void approvals. ### Step 41 - Inspect what the emergency transaction actually does The Authenticator shows eosio::updateauth for the active permission. Verify Permission: active, Parent: owner, and that the authority contains the new public key only, with the intended threshold and weight. This removes the compromised old active keys and passkeys from the active permission. Next, eosio.msig::invalidate invalidates the account's earlier recorded MSIG approvals so a previously stored approval cannot simply be reused for execution. This does not itself delete every proposal; pending proposals may remain visible. The screenshot labels this action as unverified format, so inspect its account field. Check the complete request, then sign with @owner. Why are both actions needed? updateauth stops the stolen key from giving new active approvals. invalidate addresses approvals the stolen key may have already given. Changing the public key alone does not reliably revoke those older approvals. ### Step 42 - Verify recovery before assuming the account is safe After the transaction is confirmed, inspect [Account](https://www.blocksfinity.com/account) -> Chain Data -> Keys and verify that the compromised credentials no longer appear under active. Then sign a harmless operation using the newly controlled key, inspect open MSIG proposals, and check history for any completed transfers. Re-register any legitimate passkeys or extra signing accounts only after the incident is under control. A proposer may cancel a still-open proposal. Other requested signers can also unapprove their own signatures. But do not rely on an advisory Against signal or an unapproval signed with a compromised key as your main defense. Emergency recovery is a time-sensitive change to on-chain authority, and it cannot reverse transfers that have already executed. ## Part 9 - How to disable Safe Mode again You may eventually decide to remove Safe Mode, for example on a disposable practice account or while deliberately reconfiguring security. Disabling it removes the time-delay protection on the contracts being unlinked. Do not do this during an active security incident merely to regain convenience. ### Step 43 - Start deactivation as owner While signed in as youraccount@owner, open [Wallet -> Security](https://www.blocksfinity.com/wallet/security) and select Disable Safe Mode. Blocksfinity warns that ordinary active authorization will again be available for transfers, RAM, REX, voting, and key changes after the restrictions are removed. The screen containing both the emergency and deactivation controls was shown in Step 38: Read the confirmation and select Disable Safe Mode only if you intend to remove the delay. ### Step 44 - Inspect the first deactivation action Open Authenticator as owner. The first screenshot shows eosio::limitauthchg with Allow_perms and Disallow_perms empty. This clears the additional restriction that previously allowed only owner to change account permissions. It reverses the Allow_perms: owner setting used when you enabled Safe Mode. What does this mean? The normal on-chain permission-change rules apply again. A key that satisfies active may once again have authority to change permissions that the owner-only restriction had prevented it from changing. Protect that key accordingly. ### Step 45 - Inspect every contract unlink and delete The next actions are eosio::unlinkauth. Unlink Auth removes a contract/action's custom required-permission mapping. For these whole-contract links, removing the mapping means the corresponding actions return to their default or other applicable authorization rules; the safemode delay no longer applies through that link. Check all four unlinkauth actions shown here: - eosio: system and resource functions. - core.vaulta: $A token actions. - eosio.token: $EOS token actions. - token.rms: the additional $V contract you linked during this mission. Important: The illustrated deactivation request does include token.rms, so you do not need to unlink it a second time if this transaction successfully removes that exact link. If you protected other contracts or individual actions, inspect the request and later the on-chain account carefully. Do not assume every extra link was included just because the four illustrated ones were. The last action is eosio::deleteauth, which deletes the now-unused safemode permission. The links must be removed first because a permission still required by contract links should not simply disappear. Verify Permission: safemode, Account: yours, and Authorized_by: owner, then review the entire batch and select Sign. ### Step 46 - Verify that deactivation really completed Return to [Account](https://www.blocksfinity.com/account) -> Chain Data -> Keys. Check that: - The safemode permission is gone. - owner and active still have the key arrangements you intended. - The custom whole-contract links for eosio, core.vaulta, eosio.token, and token.rms were removed as intended. - No extra action-level or whole-contract links still point to safemode. Finally, make a tiny transfer with active and verify its actual authorization and result. If it still schedules a delayed MSIG, inspect the remaining permission mappings rather than assuming the website is wrong. Before using an account with substantial liquid value: Five minutes was only for our lesson. Reconfigure Safe Mode under owner with a planned delay of at least 24 hours, and verify that the on-chain wait is at least 86,400 seconds and the intended token contracts are protected. Do not move significant funds into the account until recovery, alerts, links, and the new delay have all been tested. The exact workflow for changing an already enabled Safe Mode delay is not shown in these screenshots; use a verified owner-authorized reconfiguration process rather than guessing; then when Safemode and Active permission are perfectly configured, consider rotating to a newly generated, offline-only owner key as taught in [Mission 7](https://help.blockzhub.io/articles/mission-7-backup-recover-and-ensure-separate-permission-keys), after securely backing it up and verifying access, to reduce internet, online exposure for the owner permission. ## What just happened? You did more than click buttons: - You checked that your owner recovery authority was available before changing account security. - You used owner to create safemode with an active contribution and a time-delay contribution. - You linked selected contracts to safemode and restricted permission edits to owner. - You created and approved a delayed MSIG proposal with active, waited, executed it, and checked the actual transfer. - You protected another token contract and inspected how a manual MSIG proposal requests approvals from multiple accounts. - You learned why emergency recovery needs both updateauth and eosio.msig::invalidate. - You learned how Safe Mode is removed: clear the permission-change restriction, unlink every protected contract, and delete the safemode permission. ## What you should remember - Safe Mode is an on-chain permission and waiting period, not a second wallet or a reversible transaction. - One active approval plus time can meet the illustrated Safe Mode threshold; other MSIG configurations may require multiple people. - Protection is contract-specific. Extra token contracts must be linked, and action-level overrides must be checked. - Propose, approve, wait, execute, verify are separate stages. An alert or proposal alone is not a completed transfer. - Alerts need a realistic response window. Five minutes is for practice; use at least 24 hours as a starting point for a significant-value account and maintain recovery readiness. - Emergency recovery must remove compromised active keys and invalidate recorded approvals. Disabling Safe Mode removes the delay and should be done deliberately. ## Quick Quiz ### 1. Why does the five-minute Safe Mode example work with only one active signer? - A. The Authenticator secretly signs twice. - B. Your active authority contributes weight 1 and the elapsed 300-second wait contributes weight 1 to a threshold of 2. - C. An email alert counts as the second signature. - D. Your tokens are stored inside Blocksfinity until the wait ends. ### 2. You create and approve a Safe Mode proposal for 0.0001 $A but have not executed it. What is true? - A. The recipient already received the $A. - B. The recipient must enter your private key. - C. The proposed action is stored and approved, but the underlying transfer has not yet executed. - D. The transfer can no longer be inspected. ### 3. You want the same protection for $V held under token.rms. What must you check? - A. That token.rms is linked to safemode, with no conflicting more-specific authorization for the actions you care about. - B. That the token is displayed next to $A in your wallet. - C. That your email alerts include Transfers. - D. That $V and $A have the same price. ### 4. Why does the emergency action include eosio.msig::invalidate? - A. To send the account balance to a backup wallet. - B. To recover a forgotten owner private key from Blocksfinity. - C. To delete the Vaulta blockchain transaction history. - D. To invalidate previously recorded MSIG approvals that a compromised active key may already have given. ### 5. When disabling Safe Mode, what does eosio::unlinkauth do? - A. Deletes all tokens from the account. - B. Removes the selected custom permission link so actions are no longer required to use safemode through that link. - C. Removes the owner permission permanently. - D. Approves every pending MSIG proposal. Answer footnote: Q1:2; Q2:3; Q3:1; Q4:4; Q5:2.