# Mycel Litepaper v0.1

## What is Mycel?

Mycel is a decentralized platform that enables the transfer, management, and trading of various accounts across different blockchain platforms. It allows users to create a **"Transferable Account"** that combines their own account with a threshold signature scheme (TSS) signed by validators on Mycel. Mycel is built with Cosmos SDK and Tendermint.

Mycel enables you to:
- Exchange assets across different blockchain platforms
- Transfer assets on any chain from smart contracts or rollups on any other chain
- Buy and sell accounts tied to specific activities

## Architecture
Mycel's decentralized architecture ensures that no single party has control over the transferable account or the assets within it, maintaining the security and integrity of the users' assets.

### Transferable Account
A Transferable Account (TA) on Mycel is a specialized account structure designed to facilitate secure, cross-chain asset management and transfer. It operates using a 2-of-2 multi-signature mechanism, ensuring that both the user and the validators collectively control the account. This design enhances security and decentralization, as no single party can unilaterally control the account or its assets.


**Alice**: A user.
**TSS Account**: An account operated by validators.
**Transferable Account**: An account on Mycel managed by a 2-of-2 multi-signature, consisting of Alice and the TSS account.

#### Create Account
Creating a transferable account involves securely linking a user's Bitcoin account to a Mycel account through a series of coordinated actions that ensure the integrity and security of the account creation process. The steps are as follows:

sequenceDiagram
		autonumber
		box Alice
			participant AM as Mycel Account
		end
		box Mycel
			participant V as Validators
        participant TSS1 as TSS Account　1
			participant M as Multisig Contract
		end
		box Bitcoin
			participant TA as Transferable Account
		end
        AM->>V: execute tx with signature
	    V->>V: verify Alice's signature
        V->>M: execute tx to create multisig
        M->>M: create multisig signer
        M->>AM: assign signer of multisig

1. Alice initiates a transaction from her Mycel account and signs it.
2. Validators verify Alice's signature to confirm her identity.
3. Validators execute a transaction to update the multisig contract.
4. The multisig contract assigns Alice's Mycel account as a signer.

#### Transfer Account
Transferring a Transferable Account from one user (Alice) to another (Bob) involves the following steps:

sequenceDiagram
		autonumber
		box Alice
			participant AM as Mycel Address
		end
		box Bob
			participant BM as Mycel Address
		end
		box Mycel
			participant V as Validators
      participant TSS as TSS Account
			participant M as Multisig Contract
		end
		box Bitcoin
			participant TA as Transferable Account
		end
		
        AM->>M: execute tx to update multisig with Alice's signature
        AM->>V: execute tx to offer to update multisig
        V->>TSS: collect signature to execute tx  
        TSS->>M: execute tx to update multisig with TSS's signature
        M->>M: update signer
        M->>BM: assign signer of multisig

1. Alice initiates a transaction to update the multisig contract with her signature, indicating her intent to transfer the TA.
2. Validators receive the transaction and collect signatures from the TSS account to authorize the transfer.
3. TSS account signs the transaction and the multisig contract is updated to replace Alice with Bob as the new signer.
4. The multisig contract is updated, making Bob the new authorized signer for the TA.

#### Request Signature
Requesting a signature for a transaction (e.g., sending BTC from a Bitcoin account) involves the following steps:

sequenceDiagram
		autonumber
		box Alice
			participant AB as Bitcoin Account
			participant AM as Mycel Account
		end
		box Mycel
			participant V as Validators
      participant TSS1 as TSS Address
			participant M as Multisig Contract
		end
		box Bitcoin
			participant TA as Transferable Account
		end
		
        AM->>M: execute tx to sign Bitcoin tx to send BTC 
        AM->>V: execute tx to offer sign Bitcoin tx
        V->>TSS1: collect signature to execute tx
        TSS1->>M: execute tx to sign Bitcoin tx to send BTC
	    M->>TA: execute tx on Bitcoin to send BTC
	    TA->>AB: Send BTC on Bitcoin

1. Alice initiates a transaction from her Mycel account to sign a Bitcoin transaction to send BTC.
2. Validators receive the transaction and collect signatures from the TSS Address.
3. TSS Address sign the transaction, authorizing the multisig contract to execute the Bitcoin transaction.
4. The transaction is executed on the Bitcoin , and BTC is sent to Alice's Bitcoin account.

### Key Generation

Mycel is a decentralized platform that aims to provide secure and private transactions while maintaining the integrity and verifiability of the system. One of the key components in achieving these goals is the use of threshold signatures, specifically the [Flexible Round-Optimized Schnorr Threshold (FROST) signature scheme](https://eprint.iacr.org/2020/852).

One of the primary reasons Mycel has chosen to employ FROST is its unique property of maintaining a fixed public key, even when the set of signers changes. In Mycel, users' assets are held in transferable account, each associated with a unique public key. The security and ownership of these FAs are distributed among a group of validators using FROST.

#### Generate Key

**Round1**

Every validator $V_i$ samples $t$ random values $a_{(i,j)}$ and use these values coefficients define a degree $t-1$ polynomial $f_i(x)$

$$
a_{(i,j)} \leftarrow \mathbb{Z_q} \forall 0 \leq t< n
$$
$$
f_i(x)=a_{(i,0)} + a_{(i,1)}x+...+a_{(i, t-1)}x^{t-1}
=\sum^{t-1}_{j=0} a_{(i,j)}x^j
$$

Each $V_i$ computes a commitment polynomial $F_i(x)$

$$
\phi_{(i,j)}=a_{(i,j)}G\\
F_i(x)=\sum^{t-1}_{j=0}\phi_{(i,j)}x^i\\
=f_i(x)G
$$

Each $V_i$ computes a proof of knowledge to the corresponding $a_{i,0}$ by calculating $\sigma_i$
$k_i$ is a random nonce
$\beta$ is a context string unique to this DKG execution, which prevents replay attacks

$$
k_i \leftarrow \mathbb{Z_q}\\
R_i = k_iG \\
c_i = H(i,\beta,\phi_{(i,0)}, R_i)\\
s_i = k_i + a_{(i,0)} c_i \\
\sigma_i = (R_i, s_i)
$$

Each $V_i$ broadcast $F_i(x) , \sigma_i$ to all other validators though `VoteExtension`

Upon receiving them, $V_i$ verifies $F_j(x) , \sigma_l (1\leq j \leq n, j \neq i)$ by checking

$$
s_jG = R_j+c_j
\phi_{(j,0)}
$$

**Round2**

Each $V_i$ securely sends to each other validator $V_j$ a secret share $(j,f_i(j))$ which encrypted with validator public key.

And verifies their shares by calculating:

$$
F_i(j)=f_i(j)G
$$

Each $V_i$ calculates signing share $s_i$ by

$$
s_i=f_1(i)+f_2(i)+...+f_n(i)\\
=\sum^n_{j=1}f_j(i)
$$

Each $V_i$ calculate their publish verification polynomial $F(x)$ and this will be stored with user id (Mycel ID)

$$
F(x) =F_1(x)+F_2(x)+...+F_n(x)\\
= \sum^n_{i=1}F_i(x)
$$

#### Signing

**Preprocess**

Create $\pi (1\leq j \leq \pi)$ nonce pair $(d_{ij}, e_{ij})\leftarrow \mathbb{Z}^*_q \times \mathbb{Z}^*_q$ and commitment share $(D_{ij}, E_{ij})$

$$
(D_{ij},E_{ij}) = (d_{ij}G, e_{ij}G)
$$

**Sign**

Validator (SA) receives message $m$ from user and verify owner. then SA select $t$ validators ($V_i$) and send them unused nonce pair $B$ and $m$

Each $V_i$ compute their response $z_i$ by

$$
\rho_i=H(i,m,B)\\
R=\prod D_j (E_j)^{\rho_j}\\
c=H(R,Y,m)
$$

$$
z_i=d_i+(e_i\rho_i+\lambda_is_i c)\\
z=\sum{z_i}
$$

SA publish signature $\sigma=(R,z)$and each $V_i$ delete used nonce pair

## What to Build
### Exchange assets across different blockchain platforms
Transferable Account serves as a gateway for interacting with native assets on any chain like Ethereum-based account-based chains (e.g., ERC-20 tokens) and Bitcoin-based UTXO-based chains (e.g., BTC)

1. Deposit Assets and Submit Intent:
- Alice submits her intent, specifying the desired asset swap.
- eg: exchanging 1 BTC on the Bitcoin network for ETH on the Ethereum network.
2. Intent Resolution and Asset Transfer:
- The submitted intent is processed by a Solver, an entity responsible for matching and executing the swap
3. Transfer Validation
- Application validates the asset transfer to ensure its integrity and correctness.
4. Update Ownership:
- Upon successful validation, the ownership of the FA is transferred from the Swapper to the Solver.

### Transfer assets on any chain from smart contracts or rollups on any other chain
Transferable Accounts can be accessed and utilized from any chain using callback functions. This allows for seamless asset transfers and interactions between smart contracts or rollups on different chains. The steps involved in transferring ownership of a transferable account containing BTC from an Ethereum smart contract are as follows:

sequenceDiagram
    autonumber
    box Ethereum
        participant SC as Smart Contract
        participant AM as Mycel Contract
    end
    box Mycel
        participant V as Validators
        participant TSS as TSS Accounts
        participant M as Multisig Contract
    end
    box Bitcoin
        participant TA as Transferable Account
    end
    SC->>AM: Initiate transfer of TA ownership
    AM->>V: Notify validators of the transfer request
    V->>TSS: Collect signatures for ownership transfer
    V->>M: Execute transaction to update multisig contract
    M->>M: Update owner of Transferable Account
    V->>SC: Notify Ethereum smart contract of successful transfer

1. Initiate Transfer from Ethereum Smart Contract:
A smart contract on Ethereum initiates the process by calling a function to transfer the ownership of a transferable account containing BTC.
2. Execute Callback Function on Mycel:
Mycel's infrastructure triggers a callback function to process the ownership transfer of the TA.
3. Validator Confirmation:
Validators on Mycel verify the transaction details and signatures to confirm the transfer request.
4. Update Ownership:
Upon confirmation, the ownership of the Transferable Account is updated to the new owner specified by the Ethereum smart contract.
5. Notify Smart Contract:
The Ethereum smart contract is notified of the successful ownership transfer.

### Buy and sell accounts tied to specific activities
Design an account activity market place where buyers and sellers can interact directly to buy, sell, or trade transferable accounts. This will enable parties to discover new trading opportunities and negotiate prices in a decentralized manner.

## References
- FROST: Flexible Round-Optimized Schnorr Threshold Signatures https://eprint.iacr.org/2020/852
- Modifying FROST Signers and Threshold https://gist.github.com/nickfarrow/64c2e65191cde6a1a47bbd4572bf8cf8
- Intro to ABCI v2 (aka ABCI++) https://informal.systems/blog/intro-to-abci-v2