Multisig Lambda Contract

The Multisig Lambda Contract is a significant leap in smart contract programming due to its use of the sp.lambda type. It introduces the possibility of executing arbitrary functions that aren’t predetermined at the time of contract deployment. Here’s a detailed overview of its main components:

1. Initial Parameters: The contract is initialized (__init__) with a list of members who are allowed to propose and sign proposals, and the minimum number of required signatures to execute a proposal. These are stored in the contract’s storage (self.data), creating a reference record for the contract to operate.

2. Propose Function: The propose function serves to create new proposals. Members can submit lambda functions (comprising of arbitrary operations) that they’d like the contract to execute. These proposals are stored in a big_map data structure, with each proposal assigned a unique identifier.

3. Sign Function: The sign function facilitates proposal endorsement. Members can sign to support proposals. These signatures, attached with the unique proposal identifier, are collected and maintained in a separate big_map.

4. Execute Function: The execute function represents the crux of the contract’s operation. If a proposal has gathered the required number of signatures, members can invoke this function to execute the proposed lambda function, applying it to the contract’s storage.
   The Multisig Lambda Contract offers a broad versatility, suitable for scenarios requiring complex, flexible, and potentially dynamic control structures, such as DAOs (Decentralized Autonomous Organizations), wallet services with multiple owners, and complex DeFi protocols.

This contract requires an execution of arbitrary lambda functions with multiple signatures. It introduces the concepts of submitting and signing lambda functions. Let’s dissect its functions:

1. submit_lambda: This function allows members to submit lambda functions to the contract. This is essentially proposing a contract operation that requires multisignature approval. In the right panel of the SmartPy IDE, upon successful submission of a lambda function, you’ll observe a new transaction initiated by the sender’s address to the contract’s address.
   

2. vote_lambda: This function allows members to cast their votes (signatures) in favor of a submitted lambda function. After voting, in the IDE panel, you’ll notice a new transaction from the member’s address to the contract’s address.
   

MultisigAction Contract

The MultisigAction Contract ushers a democratic voting mechanism into the realm of smart contracts. In this model, members propose specific actions, vote on them, and execute them upon reaching a quorum. This contract presents a unique blend of human consensus with automated contract execution, enforcing a democratic control over contract behavior.

The core components of this contract are:

1. Initial Parameters: Just like in the Lambda contract, the MultisigAction Contract takes a list of members and the number of required votes during initialization.

2. Propose Action Function: This function serves to add new proposals. Members can submit actions that are predefined in the contract, associating them with a unique identifier. These proposed actions get stored in a big_map.

3. Vote Action Function: This function is designed to cast votes in favor of the proposed actions. The votes are associated with the unique identifier of the proposal and are kept in a distinct big_map.

4. Execute Action Function: This function comes into play when a proposal has garnered enough votes. Members can call this function to execute the proposed action.
   The MultisigAction Contract is ideal for situations where a group of individuals needs to reach consensus on specific contract actions, such as in DAOs where members vote on resource allocation or protocol changes.

5. submit_proposal: This is the process of proposing a new action. In the context of our example, a member is proposing to add a new signer to the contract.

6. When this operation is performed on the SmartPy IDE, you will see a new transaction being created in the IDE’s right panel. The transaction summary will indicate the sender (the proposing member’s address) and the recipient (the contract’s address). It might look something like this:
   

Here, the ‘OK’ status shows that the proposal was successfully submitted.

1. vote_proposal: The next step is voting for the proposal. This function enables existing signers to vote on the proposal submitted in the previous step.

2. When signer 1 votes for the proposal, you’ll see a new transaction, with signer 1 as the sender and the contract as the receiver. A similar transaction will be logged when signer 2 votes for the proposal:

These transactions indicate that both signer 1 and signer 2 have successfully cast their votes for the proposal.

MultisigView Contract

The MultisigView Contract carries the democratic consensus concept forward but applies it to arbitrary bytes instead of predefined contract actions. This contract opens up avenues where consensus can be achieved on data represented as bytes, without immediately leading to action execution.

The main building blocks of this contract are:

1. Initial Parameters: As with the previous contracts, the MultisigView Contract initializes with a list of members and a number indicating the required votes.

2. Submit Proposal Function: This function enables members to introduce new proposals in the form of arbitrary bytes. The bytes are stored in a big_map, indexed by the bytes themselves, representing a unique proposal identifier.

3. Vote Proposal Function: This function permits members to endorse the proposals. The votes are tracked in a separate big_map, linked to the unique bytes identifier of the proposal.
   

4. Is Voted Function: This function, an on-chain view, checks if a proposal has acquired the required votes. It returns a boolean value indicating the voting status of the proposal.
   The MultisigView Contract is particularly useful in cases where the smart contract needs to maintain a record of approved proposals, like in cryptographic applications where bytes could represent hashed agreements, proofs, or any other form of data that requires collective approval.