System

Design Overview

Aptos have a native multi-sig transaction standard (https://aptos.dev/concepts/basics-accounts/#multisigner-authentication). We adopt the this standard, combining with some on-chain storage (MOVE modules logics) to store the data required for multi-sig transactions. The overall process for a transaction works as follows:

1. Users sign transactions and submit the payload and signatures to a MSafe MOVE module, and essential transaction data is stored on-chain.

2. The last user who collects enough signatures will assemble signature and submit the transaction via Aptos core multi-ed25519.

3. After the Multi-ed25519 transaction is verified and finalized on blockchain, the user specified entry function is executed in MOVE VM.

Based on the system architecture, MSafe protocol has the following merits:

1. Security:

The MSafe design ensures that our product has the same level of security as Aptos core protocol.

Because the last step MSafe transaction is executed by Aptos native multi-ed25519 standard, MSafe wallet is secured Aptos core protocol. The only vulnerability is that the signing function implemented in Aptos core protocol is compromised, which is almost impossible and secured by cryptography premises.

This also help MSafe free from some other potential security concerns of smart contract implementation of multi-sig wallet, like double spending, transaction execution sequence, e.t.c. All these concerns have been already addressed in Aptos transaction model.

2. Interoperability

Other than being used just as a wallet, MSafe makes it possible to interact with other protocols / dApps on MOVE ecosystem. By using the native multi-ed25519 wallet from Aptos, MSafe can send transactions with any transaction payload supported by Aptos core, especially calling any entry functions from any MOVE modules.

This allows MSafe to interact with any system / third party MOVE modules, and will lead to various use cases and features supported by MSafe, including

1. Treasury management.

2. Interact with any third party dApps.

3. Interact with system function publish_function to publish a move module owned by MSafe.

4. Serve as a admin account of a move module to control over the protocol level parameters.

3. True decentralization

In our current design, data storage for MSafe is handled as follows:

1. Transaction related essential data (Single signed address, MSafe wallet, TxnBook) will be stored on-chain in MOVE modules. This will allow transactions to have as less dependancies as possible, and have no single point failure.

2. User customized / specific data are stored off-chain to provide extra user-friendly features. These data are user specific and users may not want to expose these data on chain. So we provide storage for these data in a centralized database / local storage to provide better user experience, as well as flexibility and privacy.

With this different level of data storage model, we are able to provide a decentralized system where the essential dependencies of transaction execution is only the blockchain itself, and also have the extensibility and flexibility to provide user-friendly experience.