Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARC-55 On-Chain Msig Apps #254

Merged
merged 7 commits into from
Dec 8, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
245 changes: 245 additions & 0 deletions ARCs/arc-0055.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,245 @@
---
arc: 55
title: On-Chain storage/transfer of Msig, Txn, Sig
description: A smart contract that stores transactions and signatures for simplified multisignature use.
author: Steve Ferrigno (@nullun)
discussions-to: https://github.com/algorandfoundation/ARCs/issues/254
status: Draft
type: Standards Track
category: Interface
created: 2023-10-16
requires: 4
---

## Abstract

This ARC proposes the utilization of on-chain smart contracts to facilitate the storage and transfer of multisignature metadata, transactions, and corresponding signatures for the respective multisignature sub-accounts on the Algorand blockchain.

## Motivation

Multisignature (multisig) accounts play a crucial role in enhancing security and control within the Algorand ecosystem. However, the management of multisig accounts often involves intricate off-chain coordination and the distribution of transactions among authorized signers. There exists a pressing need for a more streamlined and simplified approach to multisig utilization, along with an efficient transaction signing workflow.

## Specification

The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this document are to be interpreted as described in <a href="https://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>.

### ABI

A compliant smart contract, conforming to this ARC, **MUST** implement the following interface:

```json
{
"name": "ARC-55",
"desc": "On-Chain Msig App",
"methods": [
{
"name": "arc55_deploy",
"args": [
{
"name": "threshold",
"type": "uint64",
"desc": "Initial multisig threshold, must be greater than 0"
}
],
"desc": "Deploy a new On-Chain Msig App.",
"returns": {
"type": "uint64",
"desc": "Msig App Application ID"
}
},
{
"name": "arc55_update",
"args": [],
"desc": "Update the application",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_destroy",
"args": [],
"desc": "Destroy the application and return funds to creator address. All transactions must be removed before calling destroy",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_addAccount",
"args": [
{
"name": "index",
"type": "uint8",
"desc": "Account position within multisig to add"
},
{
"name": "account",
"type": "account",
"desc": "Account to add"
}
],
"desc": "Add account to multisig",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_removeAccount",
"args": [
{
"name": "index",
"type": "uint8",
"desc": "Account position within multisig to remove"
}
],
"desc": "Remove account from multisig",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_setThreshold",
"args": [
{
"name": "threshold",
"type": "uint64",
"desc": "New multisig threshold, must be greater than 0"
}
],
"desc": "Update the multisig threshold",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_addTransaction",
"args": [
{
"name": "index",
"type": "uint8",
"desc": "Transaction position within atomic group to add"
},
{
"name": "transaction",
"type": "byte[]",
"desc": "Transaction to add"
}
],
"desc": "Add transaction to the app. Only one transaction should be included per call",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_removeTransaction",
"args": [
{
"name": "index",
"type": "uint8",
"desc": "Transaction position within atomic group to remove"
}
],
"desc": "Remove transaction from the app. Unlike signatures which will remove all previous signatures when a new one is added, you must clear all previous transactions if you want to reuse the same app",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_setSignatures",
"args": [
{
"name": "signatures",
"type": "byte[][]",
"desc": "Array of signatures"
}
],
"desc": "Set signatures for account. Signatures must be included as an array of byte-arrays",
"returns": {
"type": "void",
"desc": ""
}
},
{
"name": "arc55_clearSignatures",
"args": [
{
"name": "account",
"type": "account",
"desc": "Account whose signatures to clear"
}
],
"desc": "Clear signatures for an account. Be aware this only removes it from your local state, and indexers will still know and could use your signature",
"returns": {
"type": "void",
"desc": ""
}
}
]
}
```

Each deployment is administered by the creator's address, who is responsible for configuring the multisignature metadata, which includes the threshold and sub-accounts, and adding or removing transactions. After successful deployment and configuration, the application ID **SHOULD** be distributed among the involved parties as a one-time off-chain exchange.

Each constituent of an on-chain multisignature application **SHOULD** OptIn to the application ID. This OptIn serves two primary purposes: it allocates the minimum balance requirement for storing up to 16 signatures in their local state, and it enables any local infrastructure, such as wallets, to track changes in the application's state and notify the user of any new transactions requiring their signature.

Once a transaction receives enough signatures to meet the threshold and falls within the valid rounds, anyone **MAY** construct the multisignature transaction, including all the signatures, and submit it to the network. Subsequently, participants can clear the signatures from their local state, and the administrator can remove or replace the transactions.

When an on-chain multisig application is no longer needed, the administrator may destroy the application, reclaiming any Algo funds used for storing the transactions in boxes. Destroying the application does not render the multisignature account inaccessible, as a new deployment with the same multisignature metadata can be configured and used.

Below is a typical expected lifecycle:

* Admin deploys Msig App, with a threshold of 2.
* Admin adds 2 accounts to form a new multisig.
* Admin adds a new transaction to sign.
* Account 1 provides their signatures.
* Account 2 provides their signatures.
* Anyone can now submit the transaction to the network.
* Admin clears the signatures of each account.
* Admin removes the transaction since it's now committed to the network.
* Admin is ready to add a new transaction.

### Storage

| Type | Key | Value | Description |
|--------|-------------|---------|----------------------------------------------------------|
| Global | "Threshold" | uint64 | The multisig threshold |
| Global | uint8 | Account | The sub-account index for the multisig |
| Global | Account | uint64 | The number of times this account appears in the multisig |
| Local | uint8 | byte[] | The signature for the nth-indexed transaction |
| Box | "txn"+i | byte[] | The transactions available for signing "txn0", "txn1"... |

### Cost

Given that all interactions occur on-chain, there are associated costs, excluding the standard transaction fee. Below is an approximate breakdown of the minimum additional costs going by the current costs. Note that a smart contract implementation **MUST** not hardcode any of these values and instead use the AVM's global values to calculate if payments have been met:

| Action | Storage Cost (microAlgos) | Breakdown |
|-----------------|--------------------------|---------------------------------------------------|
| Creation | 250,000+ | 100,000 + (50,000 * (1 + (2 * NumOfSubAccounts))) |
| OptIn | 900,000 | 100,000 + (25,000 + 25,000) * 16 |
| Add Transaction | 72,100+ | 2,500 + (400 * (4 + TxnSize)) * NumOfTxns |

## Rationale
### Limitations and Design Decisions

The current design necessitates that all transactions within the group be exclusively signed by the constituents of the multisig account. If a group transaction requires a separate signature from another account or a logicsig, this design does not support it. An extension to this ARC **SHOULD** be considered to address such scenarios.

This ARC inherently promotes transparency of transactions and signers. If an additional layer of anonymity is required, an extension to this ARC **SHOULD** be proposed, outlining how to store and share encrypted data.

Having individual deployments for different groups rather than a single instance that everyone uses has benefits for third-party infrastructure. Managing a large number of boxes for a single application can be cumbersome. Instead, small groups can create their multisig app by having one member deploy the contract. They can then subscribe to the application ID, simplifying the tracking of multisig applications and transactions for wallets and other infrastructure.

## Reference Implementation

A TEALScript reference implementation is available at <a href="https://github.com/nullun/arc55-msig-app">`github.com/nullun/arc55-msig-app`</a> or an older TEAL implementation at <a href="https://github.com/nullun/MsigShare">`github.com/nullun/MsigShare`</a> with a user interface at <a href="https://github.com/nullun/MsigShareUI">`github.com/nullun/MsigShareUI`</a>. It is encouraged for others to implement this standard in their preferred smart contract language of choice and even extend the capabilities whilst adhering to the provided ABI specification.

## Security Considerations

This ARC's design solely involves storing existing data structures and does not have the capability to create or use multisignature accounts. Therefore, the security implications are minimal. End users are expected to review each transaction before generating a signature for it. If a smart contract implementing this ARC lacks proper security checks, the worst-case scenario would involve incorrect transactions and invalid signatures being stored on-chain, along with the potential loss of the minimum balance requirement from the application account.

## Copyright
Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.
Loading