To move funds in Utila, someone must sign the transaction. Under Utila's MPC protocol, the signing key exists as two key shares in two separate places:

When you sign, the two shares work together to produce a signature. That signature is what authorizes the transaction. The key itself is never reconstructed, and Utila never holds a complete private key.

If every signing device is lost, and you have no backups, you can be locked out of the funds. Phones are easier to lose, break, or wipe than people expect. The following practices reduce that risk.

Each person who signs must set up a personal backup and keep the recovery phrase in a safe place. Write it on paper and store it in a safe. Do not take a screenshot of it, email it, or save it in a notes app.

The phrase lets that person restore their key share on a new phone. You create a personal backup in the Utila app. It does not need an admin quorum.

A new device may still need admin approval before it can be used. If someone has no personal backup, another person with a working signing device can help set up the new device after that approval.

For more details, read the article Introduction to personal backup of device keys.

The article Create a personal backup of device keys provides step-by-step instructions.
​

Do not depend on a single person or a single phone. Give at least two other people a role that can sign, such as Admin or Signer.

Admins should also set up at least one spare device, store it securely, and confirm it can still sign.

If someone only needs to view activity or does not need to sign, do not give them a signing role.​

Utila's backup and recovery solution ensures access to your assets in the unlikely event that Utila's core infrastructure is impacted by an unrecoverable disaster, or you lose access to your signing devices.

Utila recommends creating a disaster recovery kit with one of our selected partners.

For details, read the article Introduction to disaster recovery.

Technically advanced customers can also consider managing their own disaster recovery keys. For details, read the article Introduction to self-managed backup of vault keys.​

Some actions are especially sensitive, such as changing user roles, setting a transaction policy, or approving a new device. Those should require more than one admin, or named admins, whenever you can.

The minimum is one administrator. Use more than one so a single missing admin cannot block routine operations or recovery.
​

Policies control which transactions can go ahead and who must approve them. They can allow a transaction, require more approvals, or stop it. They do not send the transaction on their own. A person or a co-signer still signs.

Set policies that match how your organization actually moves funds.
​

Not everyone needs the same access. If a person does not need to approve vault actions, do not make them an admin.
​

If possible, use a phone for Utila that is not the same phone used for mail, chat, and browsing. A separate phone reduces how often the signing device is exposed to everyday risk.
​

Keep spare devices stored securely and unused except when you test them. Confirm they still work after you add people, wallets, or new chains.
​

On a regular schedule, review users, devices, personal backups, and the vault backup. Test that you can still recover. Remove access for people who no longer need it.

If you are getting a new phone, restore access on the new phone, confirm you have your personal backup recovery phrase, and only then erase the old phone. If you can still sign but do not have access to your personal backup recovery phrase you may create a new personal backup.

Moving to a new iPhone or Android phone does not copy Utila key shares. Those shares stay on the old device, in its secure hardware, and are tied to the Utila app.
​

Do not delete the Utila app or change the phone's biometrics until you have a working personal backup, or another live device that can restore your access.

Deleting the app can erase the key shares on that phone. Changing biometrics can make those shares unreachable.
​

Before you remove someone, confirm other people still have working devices and that admins can still approve actions. Then revoke that person's access.