# Phala Contract Design (lab note)
*This will serve as a brain storming area for the design and UX for phala contract.*
*This design is based on front-end UX.*
*Ordum has to be generic to acomodate other types of ecosystem grants.*

**Table of contents**
1. [Abstracted functionalities for users](#a)
2. [Global state layout](#b)
3. [Grant Issuer profile](#c)
4. [Key management](#d)

* **
<a name="a"></a>
### Abstracted functionalities for users

|Grant Issuer | Grant Applicant |
|------------------------|-------------------------|
| Create Profile | Create Profile |
| Update Profile | Update Profile |
| Delete Profile | Delete Profile |
| Review Application | Submit Application |
| Accept Application | Update Application |
|Update Controlling Keys | |

* **
<a name="b"></a>
### Global state layout
* **IssuerProfile**
-> A mapping of AccountId to grant Issuer Profile
* **ApplicantProfile**
-> A mapping of AccountId to grant Applicant Profile
* **Manage Keys**
-> A list of authorized keys for specific Account's Profile
***
<a name="c"></a>
### Grant Issuer Profile
This consist of the following properties:
1. Name of the grant
2. Description
3. Chain's name or if it's an offchain grant
4. Active status
5. Categories of which the grant is based on
6. Registration date
7. List of applications made to this grant

Note: This consist of properties that every Grant issuer profile must have to be presented in ORDUM.

We do not make any assumption on its application structure, as this will be presented as just unique IDs pointing to actual application file stored in external storage.

Meaning that all applications won't be stored on parent chain rather in external storage (eg. Crust, Storj, etc.).
* **
<a name="d"></a>
### Key Management
This is a new feature introduced to allow multiple authorized accounts to manage a **Grant Issuer Profile**.

The accounts are managed by an admin account which has authority to add and remove privileged accounts, and also, the admin can be passed to another account by the current admin. Without such a framework if the main admin account is lost all privileges of controlling the Issuer Profile would be lost.

Our proposed key management framework allows a lot of flexibility as multiple members of a team can control the account mapped to the Issuer Profile. This removes the bottleneck and the single point of failure.

**Limitations**

* Concurrent accesing of data and mutation is not prevented. The account owners must prevent this.
* Only 3 privilged accounts are allowed per **profile**, thus including Admin, key1, key2.

**Chart**

***
### POC
1. **Simplified treasury grants application**
* **
To do:
* Improve UX for front-end clients, thus including but not limited to clear low level APIs, metadata and documentation
* More testing (e2e)
* External storage
* Social consensus on treasury grants attestations (Certificates)
* Token abstraction on grant applicants
* Testing on-chain grants via chopsticks (Kusama chain)
* **
2. **Offchain grants application**

* **
### Ordum layout chart
* **

### Internal Storage (on-chain)
1. User's profiles
2. Application profile references
3. Milestone references

### External storage

* **
### Non-fee interaction for offchain grants
*Coming.....*