Release: Altair - v1.5.8

Altair - v1.5.8

Phishing attacks are becoming a prevalent issue within blockchain systems. As the crypto world welcomes more newcomers, the need for stronger protection against these scams is evident. To combat this issue, we developed Guardians, an optional security feature that users can enable to add an extra layer of protection to their accounts.

"The Great Heist" campaign, where we published the seed phrase of an account for two weeks and invited everybody to move the funds, proved the robustness of our Guardians feature. No one managed to access the funds, demonstrating the effectiveness of the security measure. You can find more information about the campaign on the heist web page. Drawing parallels to the Two-Factor Authentication (2FA) systems used by banks in their mobile applications, Guardians serve a similar purpose. Just as 2FA offers enhanced security against phishing attacks in the banking sector, Guardians acts as a proactive defense mechanism within blockchain systems.

With Guardians enabled, even if an individual's seed phrase is compromised through a phishing attack, the attacker would still need access to the second authentication factor, which is typically under the user's control. This added layer of protection greatly reduces the likelihood of successful account infiltration.

Furthermore, Guardians not only enhances security but also instills a sense of confidence and trust among users. By offering an optional security feature like this one, MultiversX demonstrates its commitment to protecting user accounts and assets. Users can feel reassured knowing that their accounts are fortified with additional security measures, making it considerably more challenging for malicious actors to exploit vulnerabilities.

However, it's important to acknowledge that no security measure is infallible, including Guardians. Attackers may employ sophisticated techniques or exploit potential weaknesses in the authentication process. Therefore, ongoing research and development efforts are crucial to continuously improve and strengthen security measures against emerging threats. On this aspect you encourage all of you to contribute, create various services that may serve as better alternatives to our own solution. On this aspect we will publish the TCS code soon.

MultiversX Guardians in short

On users

For users, to set up and manage guardians for account protection, the following transactions need to be sent:

1. Set a Guardian: To register a guardian, a user must send a SetGuardian transaction. This transaction sets the guardian address and becomes active after 20 epochs. The guardian address should be stored in the account's key-value store.
2. Guard Account: To activate guardian co-signing, a GuardAccount transaction needs to be sent to the blockchain. This transaction can only be processed if the account already has an active guardian set. Once the account is guarded, any transaction issued by the user will be ignored unless it carries the signature of the active guardian. The GuardAccount transaction can be sent directly by the user or through a relayer.
3. Sending Guarded (Co-signed) Transactions: To send a guarded transaction, the Send Transaction endpoint is used. The transaction must include the following additional fields:
4. "guardian": Represents the address of the guardian that needs to co-sign the transaction.
5. "guardianSignature": Represents the signature computed by the guardian.

In addition to these fields, the transaction's version must be set to 2, and the options field needs to have the second least significant bit set to 1. This ensures that the transaction is accepted as a guarded transaction by the protocol.

1. Deactivate Guarding the Account: To unguard the account, a guarded UnGuardAccount transaction needs to be sent. Details about this transaction can be found in the built-in functions.
2. Change the Active Guardian: If there is a need to change the active guardian, a SetGuardian transaction must be sent. The user can choose to send either an unguarded transaction (without requiring the guardian's co-signature) or a guarded transaction (if the account was already guarded). In the case of an unguarded transaction, it takes 20 days to become active, whereas a guarded transaction becomes active immediately. This ensures that the user has control over their account and can protect their funds even during unexpected changes.

It's important to note that these transactions and processes are designed to provide flexibility to users and prevent them from being locked out of their accounts. By allowing users to set and change guardians, they have the ability to maintain control and protect their funds. You can consult the full documentation here:

You may refer to the wallet extension and web wallet documentation for specific instructions on how to use this feature:

• Web-Wallet;
• Wallet extension;
• xPortal Wallet - to be updated in CW 27;

On developers

Developers can ensure their dApps successfully interact with guarded accounts by incorporating the necessary changes to handle the guardian signing process, by following these guidelines:

The guardians feature introduces an additional signing layer for transactions, requiring a Guardian to sign transactions for a guarded account. The specifications of a guarded transaction include:

• Addition of the "guardianAddress" field.
• An extra 50000 gas added to the "gasLimit".
• The "options" field must have the second least significant bit set to "1" (e.g., options: 2).
• The "version" field should be set to 2.

To format a transaction using the @multiversx/sdk-core library, the following steps must be taken:

• Set the guardian address using transaction.setGuardian(Address.fromBech32(activeGuardianAddress)).
• Set the transaction version and options using transaction.setVersion(TransactionVersion.withTxOptions()) and transaction.setOptions(TransactionOptions.withOptions({ guarded: true, hashSign: true })), respectively.

After setting these fields, the transaction must be signed by both the Guardian and the UserSigner. Note that all MultiversX signing providers handle the formatting of the transaction internally, except for Ledger. Moreover, sdk-dapp users simply need to ensure that they have updated their libraries to the latest versions:

• @multiversx/sdk-guardians-provider@1.0.2
• @multiversx/sdk-dapp@2.16.0

Whereas custom-dapp builders have to take care of a few more dependencies:

• @multiversx/sdk-core@12.4.2;
• @multiversx/sdk-extension-provider@3.0.0-alpha.1 (a proper release will follow soon);
• @multiversx/sdk-hw-provider@6.1.0;
• @multiversx/sdk-native-auth-client@1.0.4;
• @multiversx/sdk-network-providers@1.4.0;
• @multiversx/sdk-opera-provider@1.0.0-alpha.1;
• @multiversx/sdk-wallet@4.0.0;
• @multiversx/sdk-web-wallet-provider@2.4.0;
• @multiversx/sdk-wallet-connect-provider@3.2.1;

Additionally

It's important to note that this release includes other significant features and improvements. To explore all the contributions, please refer to the following GitHub link: https://github.com/multiversx/mx-chain-go/releases/tag/v1.5.8

Activation epoch

There is 1 flag that will be enabled on epoch 1075 which is scheduled to happen on July 10th, 2023 ~15:45 UTC.

• SetGuardianEnableEpoch - will activate the Guardians feature that allows any user account to be guarded by another account. The operations from the guarded account will be permitted only through transactions that are both signed by the account's private key and the guardian's private key. This feature will add extra security for user accounts if the account's private key was leaked.

Mainnet config: https://github.com/multiversx/mx-chain-mainnet-config/releases/tag/v1.5.8.0

We'd like to invite you to join us on Discord, where you can connect with fellow builders and developers. Stay up-to-date on all the exciting developments happening behind the scenes, receive support from the community and our team, and be part of the journey as the stars start to align for Sirius, our upcoming release v1.6.0. Together, let's shape the future of MultiversX!