App entities

[karl-kallavus]

Issue to help us understand what data we need to store where.

Glossary

Multisig: A wallet controlled by multiple other wallets
Timepoint: blockheight and extrinsic id of the created Multisig
Signatories: the accounts that are allowed to approve a Multisig
Threshold: a minimum amount of approvals needed for a call to be dispatched (ex. 2 of 3)
Multisig Deposit Base: reserved with the first approval
Multisig Deposit Factor: multiplied by threshold and reserved for adding 32 bytes into existing storage
Multisig Deposit: Deposit Base + Threshold * Deposit Factor
Multi Account ID: derived from a sorted list of ID’s
Proxy Account/Delegate: the account which may acts on another account’s behalf with restricted (or unrestricted) functionality
Real/Proxied Account: the account that the proxy will make a call on behalf of
Proxy Type: value that defines the subset of calls that a delegate is allowed to make
Delay: The amount of blocks that an announcement must be in place for before the corresponding call may be dispatched
Announcement: The publication of the hash of a proxy-call that will be made in the future.
Proxy Deposit Base: Amount reserved for the proxy creation
Deposit Factor: Amount reserved per proxy added for adding 32 bytes plus an instance of ProxyType into existing storage.
Total deposit: Deposit Base + Deposit Factor * number of proxies

Extrinsics

1. Create a pure proxy

Extrinsic
proxy createPure(proxyType, delay, index)

The first pure proxy should always be of type Any.

Any proxy type has permission to make any type of transaction, including balance transfers.
Without having an Any type proxy, it won't be possible to send funds, add new proxies, kill the pure proxy, or take any action not specifically allowed by the types of the proxies that have been set up for the account.

Parameters:
delay: will generally be zero (in block height)
index: will typically always remain at 0. Unless this is called multiple times in the same transaction (e.g using batch)

2. Remove a previously spawned pure proxy

Extrinsic
proxy killPure(spawner, proxyType, index, height, extrinsicIndex)

Before running killPure we need to warn a user because all access to this account will be lost. Any funds held in it will be inaccessible.

Parameters:
spawner: The account that originally called pure to create this account.
proxyType: The proxy type originally passed to pure.
index: The disambiguation index originally passed to pure. Probably 0.
height: The height of the chain when the call to pure was processed.
extrinsicIndex: The extrinsic index in which the call to pure was processed.

3. Start multisig transaction and register approvals

Extrinsics
multisig approveAsMulti(threshold, otherSignatories, maybeTimepoint, callHash, maxWeight)

Deposit will be reserved if this is the first approval. It is returned once this dispatch happens or is cancelled.
If this is the final approval, you will want to use asMulti.

multisig asMulti(threshold, otherSignatories, maybeTimepoint, call, maxWeight)

If there are enough approvals, is dispatches the call. Unless this is the final approval, you will generally want to use approveAsMulti, since it only requires a hash of the call.

Parameters:
threshold: The total number of approvals for this dispatch before it is executed.
otherSignatories: The accounts (other than the sender) who can approve this dispatch. May not be empty.
maybeTimepoint: If this is the first approval, then this must be None. If it is not the first approval, then it must be timepoint (block number and transaction index) of the first approval transaction.
callHash: The hash of the call to be executed
call: The call to be executed.

4. Cancel multisig transaction

Extrinsic
multisig cancelAsMulti(threshold, otherSignatories, timepoint, callHash)

Any deposit reserved previously for this operation will be unreserved on success.

Parameters
threshold: The total number of approvals for this dispatch before it is executed.
otherSignatories: The accounts (other than the sender) who can approve this dispatch. May not be empty.
timepoint: block number and transaction index of the first approval transaction for this dispatch.
callHash: The hash of the call to be executed.

Based on that I assume we could introduce following entities in our App:

Data Fetching

• from blockchain (utilising capi), e.g for account balances etc
• from wallet browser extension (PolkadotJS or Talisman), e.g for user accounts public keys, account names
• from centralised server (dynamodb) - for notifications, pending transactions (see below)
• from local storage - for selected chain, dark/light mode info, user preferences
• from code (via configs or hardcoded values) - for blockchain logos, constants

App entities

1. Chain

Parameters:

• Name
• Token display name (e.g DOT, UNIT etc)
• Multisig deposit base
• Multisig deposit factor
• Proxy deposit base
• Proxy deposit factor

Maybe capi could return configs with these values. Otherwise we could always hardcode them.

2. Account

Parameters:

• public key - from extension (which is a primary key for a corresponding database entity)

• balance - from blockchain

• name - from extension

• proxies - list of proxies, from database

• multisigs - list of multisigs, from database

• notications- list of pending transactions waiting approvals (or refusals)

• type: real | proxy | multisig

real

Real accounts don't require any special parameters.

proxy

Parameters (in database):

• spawner (?tbd how could we fetch this data from chain?)
• proxyType
• delay
• index
• height
• extrinsicIndex

multisig

Parameters (in database):

• threshold: number
• signatories: (e.g list of accounts)
• pendingTransactions

3. Multisig Transaction

approvedThreshold, publicKey, listOfWaitingApprovals, listOfProxies

Parameters required for extrinsics:

• threshold
• otherSignatories
• maybeTimepoint
• callHash
• maxWeight

User flows:

1. Connect wallet

Adding new Account (type Real) entity into database.

2. Create multisig.

1. Create new pure proxies.
   Adding new Account (type Proxy) entities into database.
2. Create a multisig.
   Adding new Account (type Multisig) entities into database.
   Reassign proxies delegate accounts. Editing proxies accounts fields in database.

3. User initiates a multisig transaction.

1. Adding new Multisig Transaction entity into database.
2. Signatories receives notification. (updating Account/Notifications in database)

4. User approves / rejects multisig transaction.

Updating corresponding Multisig Transaction and Account/Notifications in database.

Dynamodb data schema: (tbd)

[tukwan]

Followed on paritytech/capi#525