Parallel Universe
  • Learn
    • Introduction to PUT
    • Getting started with PUT
  • Architecture
    • What is a PUT Cluster?
    • Clusters
      • PUT Clusters
      • RPC Endpoints
      • Benchmark a Cluster
      • Performance Metrics
    • Consensus
      • Synchronization
      • Leader Rotation
      • Fork Generation
      • Managing Forks
      • Turbine Block Propagation
      • Commitment Status
      • Secure Vote Signing
      • Stake Delegation and Rewards
    • Validators
      • Overview
      • TPU
      • TVU
      • Blockstore
      • Gossip Service
      • The Runtime
  • CLI
    • Command-line Guide
    • Install the PUT Tool Suite
    • Command-line Wallets
      • Command Line Wallets
      • Paper Wallet
      • File System Wallet
      • Support / Troubleshooting
    • Using PUT CLI
    • Connecting to a Cluster
    • Send and Receive Tokens
    • Staking
    • Deploy a Program
    • Offline Transaction Signing
    • Durable Transaction Nonces
    • CLI Usage Reference
  • Developers
    • Get Started
      • Hello World
      • Local development
      • Rust program
    • Core Concepts
      • Accounts
      • Transactions
        • Overview
        • Versioned Transactions
        • Address Lookup Tables
      • Programs
      • Rent
      • Calling between programs
      • Runtime
    • Clients
      • JSON RPC API -1
      • JSON RPC API -2
      • JSON RPC API -3
      • Web3 JavaScript API
      • Web3 API Reference
      • Rust API
    • Writing Programs
      • Overview
      • Developing with Rust
      • Deploying
      • Debugging
      • Program Examples
      • FAQ
    • Native Programs
      • Overview
      • Sysvar Cluster Data
    • Local Development
      • PUT Test Validator
    • Backward Compatibility Policy
  • Validators
    • Running a Validator
    • Getting Started
      • Validator Requirements
    • Voting Setup
      • Starting a Validator
      • Vote Account Management
      • Staking
      • Monitoring a Validator
      • Publishing Validator Info
      • Failover Setup
      • Troubleshooting
    • Geyser
      • Geyser Plugins
  • Staking
    • Staking on PUT
    • Stake Account Structure
  • Integrations
    • Add PUT to Your Exchange
    • Retrying Transactions
  • Library
    • Introduction
    • Token Program
    • Associated Token Account Program
    • Memo Program
    • Name Service
    • Feature Proposal Program
    • NFT Program
      • Overview
      • Interface
      • Usage Guidelines
        • Create a new NFT-Mint
        • Cast NFT
        • Transfer an NFT
        • Change account status
        • Permission settings
        • Query Interface
        • Continuous casting
        • Change the Mint attribute
      • Operation Overview
        • Create a new NFT-Mint
        • Transfer NFT
        • Destroy
        • Freeze NFT accounts
        • Update
    • PUT multi-sign program
      • Overview
      • Interface
      • Usage Guidelines
        • Create a multi-signature account
        • Create a proposal account
        • Vote proposal
        • Verify Proposal
        • Add-singer
        • Remove-signer
      • Operation Overview
        • Create a multi-signature account
        • Create a proposal account
        • Vote
        • Verify
        • Add-singer
        • Remove-signer
  • PUT Privacy Policy
Powered by GitBook
On this page
  1. Library
  2. PUT multi-sign program

Overview

PreviousPUT multi-sign programNextInterface

Last updated 2 years ago

Running on the PUT chain, Multi-sig contract deployment defines and realizes a common multi-sig service, which provides online multi-sig service for contracts.

Contracts that need to access multi-sig can call the multi-sig program through CPI (Cross Program Invocation), while the private keys required for multi-sig are stored separately to avoid severe security problems caused by private key leakage.

Multi-sig contracts mainly provide interfaces for creating multi-sig accounts, creating proposal accounts, as well as proposal voting and proposal verification.

CPI calls the interface for multi-signature contracts, which we call the multi-signature interface.

The normal flowchart for a multi-signature interface to access a multi-signature contract is roughly as follows.

  1. Create a multi-signature account

  2. Get the address for multi-signature accounts

  3. Contract developers bind the multisig interface to a multisig account (decide which multisig account to use when developing the multisig interface)

  4. Account Alice initiates the first multi-signature interface call

  5. A transaction proposal is created on the first call and an account is created in the multi-signer by means of a Cross Program Invocation. The content of the transaction proposal is defined by the contract developer, and we recommend that the proposal outlines the user's actions (the proposal content for an A -> B transfer transaction can be written as "Alice (the proposal initiator) init a A transfer 1 PUT to B proposal.")

  6. Alice gets the address of the proposal account and gets the successful response of execution

  7. Alice, the initiator of the transaction, informs other signatories of the proposal address (proposal_address) offline, and other signatories can vote after viewing the proposal

  8. After the proposal is approved, Alice initiates a second multi-signature interface call

  9. The multi-signature interface method verifies that the proposal has passed by calling the multi-signature contract through Cross Program Invocation

  10. If the proposal is approved, the multi-signature interface starts executing the real contract logic

  11. Return a successful response

You can see that multi-signature contracts actually increase the complexity of the multi-signature interface, mainly because methods that were called once now need to be called twice by the initiator.

However, multi-signature makes the contract interface more secure. From a security point of view, it is worth increasing code complexity.