MSafe | Aptos
  • Overview
    • MSafe Overview
    • What can you do with MSafe wallet?
      • Why Multi-Sig & Non-Custodial
      • MSafe Wallet Key Benefits
    • Use Cases
      • Treasury Management
      • Smart Contract Deployment & Update
      • Protocol Admin Control
      • dApp Store Integration
    • Security
  • Users
    • Glossary
    • Launch App
    • Connect Wallet
    • Navigation Bar
    • Address Book
    • Create an Account
      • Initiate Creation
      • Co-Managers to Accept
    • Switch btw Accounts
    • Deposit / Receive
    • View Assets
    • View Pending Txn
    • View Txn History
    • Propose Transaction (Enable NFT, Send, Register Coin)
      • Enable NFT
      • Send
      • Add Coin
    • Approve Transaction
      • Co-Managers to Approve Enable NFT
      • Co-Managers to Approve Send
      • Co-Manager to Approve Add Coin
    • Change Vote
    • Reject Transaction
      • Co-Managers to Reject
    • Execute Transaction
      • Execute Approval
      • Execute Rejection
    • App Store
      • Use dApps
    • MSafe 1.0 User guide
      • Connect Wallet
      • First time registration
      • Create an MSafe Account
      • Receive Coin
      • Coin Transfer (APT)
      • DAPP Store
      • Add a new coin
      • Address Book
      • Permissions
      • Wallet FAQs
  • Developers
    • Overview
    • System
      • Auth-key & Multi-Ed25519
      • Backend Walk Through
      • MSafe Contracts
    • Interactive CLI
      • Installation
      • CLI arguments
      • Register and View
      • Create a MSafe Wallet
      • Approve / execute a transaction
      • Transfer Coin
      • Smart Contract | Module Publish
      • Entry Function
      • Reject a transaction
      • Migration from MSafe 1.0 to MSafe 2.0
    • SDK
      • Smart Contract | Deploy a MOVE Module
      • Call An Entry Function
    • Integrate with MSafe (DAPP)
      • FAQ
    • Move Module Publish
  • Product updates
    • 2022 Q4
Powered by GitBook
On this page
  • Design Overview
  • 1. Security:
  • 2. Interoperability
  • 3. True decentralization
  1. Developers

System

PreviousOverviewNextAuth-key & Multi-Ed25519

Last updated 2 years ago

Design Overview

Aptos have a native multi-sig transaction standard (). 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.

https://aptos.dev/concepts/basics-accounts/#multisigner-authentication