# JoyID DAO Lock V1 ## Metadata **Status**:: #x **Zettel**:: #zettel/permanent **Created**:: [[2023-12-11]] **Notion**:: [JoyID DAO Lock V1](https://www.notion.so/cryptape/JoyID-DAO-Lock-V1-e28bdcba388348dcbce24b4451ecefbc) ## Synopsis JoyID DAO Lock requires signing the Co-Build digest using JoyID keys. The script uses the same args schema as [JoyID Lock](https://github.com/nervina-labs/joyid-lib-demo/blob/master/docs/protocol.md#data-structure) . However, the PoC will only supports the algorithm “Secp256r1 for WebAuthn” and device main key. ## Scenarios ### S1: Depositing CKB 1. User Alice signs in using JoyID 2. Alice sees his JoyID DAO lock address 3. Alice sees the link to the testnet faucet 4. Alice deposits CKB from faucet to his JoyID DAO lock address The JoyID DAO Lock address is different from the CKB address displayed in the JoyID account page. Currently, it's impossible to deposit CKB from JoyID Lock to DAO via JoyID interface and API. ### S2: Depositing DAO 1. User Alice signs in using JoyID 2. Alice clicks the button "Deposit" and fill how many CKB to deposit into DAO 3. Alice reviews the transaction details and confirms the signing in the JoyID popup. ### S3: Listing DAO Deposits 1. User Alice signs in using JoyID 2. Alice sees a list of DAO deposits 3. Alice expand details for one deposit ### S4: Initiating DAO Withdraw 1. User Alice signs in using JoyID 2. Alice selects a deposit in the Deposits List (S3) and clicks the button "Initiate Withdraw" 3. Alice reviews the transaction details and confirms the signing in the JoyID popup. 4. Alice sees the new ongoing withdraw in the Deposits List (S3) ### S5: Completing DAO Withdraw 1. User Alice signs in using JoyID 2. Alice selects an ongoing withdraw in the Deposits List (S3, S4) 3. User fills in the recipient address. 4. Alice reviews the transaction details and confirms the signing in the JoyID popup. 5. Alice sees that the deposit is removed from the Deposits List and the account balance increases. ## Verifying JoyID DAO Lock uses the `parse_message` function in the [Co-Build PoC](https://github.com/cryptape/ckb-transaction-cobuild-poc/blob/main/docs/migration.md) to extract `message_digest` and `seal`. Then the lock script verifies whether `seal` is the correct signature of `message_digest` signed by JoyID using the provided public key. The hash of the provided public key must match the hash in the script args. The signature is generated using the API [`signChallenge`]() in the package `@joyid/ckb`. The seal has the same binary format as the [`witness_args.lock`](https://github.com/nervina-labs/joyid-lib-demo/blob/master/docs/protocol.md#data-structure) in the JoyID Lock. ``` witness_args.lock = unlock_mode | public_key(_hash, only for secp256k1) | signature | web_authn_msg ``` The PoC does not supports sub key unlocking yet. In the Co-Build protocol, `SubKeyUnlockEntries` can be stored in `Action.data` using the hash of the lock script as the `Action.script_hash`. JoyID DAO Lock uses the following Molecule schema to serialize `Action.data`: ``` union JoyIDDAOData { JoyIDDAODepositV1, JoyIDDAOWithdrawPhase1V1, JoyIDDAOWithdrawPhase2V1, } table JoyIDDAODepositV1 { locked: Uint64, occupied: Uint64, // overhead for CKB cell storage start_epoch: Uint64, // lock start time in unit epoch with fraction, inclusively } table JoyIDDAOWithdrawPhase1V1 { locked: Uint64, occupied: Uint64, start_epoch: Uint64, end_epoch: Uint64, // lock end time in unit epoch with fraction, inclusively componsation: Uint64, // gained componsation by locking CKB in DAO } table JoyIDDAOWithdrawPhase1V2 { locked: Uint64, occupied: Uint64, start_epoch: Uint64, end_epoch: Uint64, // lock end time in unit epoch with fraction, inclusively componsation: Uint64, // gained componsation by locking CKB in DAO } ``` Attention that `Action.data` is optional for the lock script. When it is omitted, users will not know the DAO depositing and withdrawing details when signing the transactions, but they still can signing any transactions. The challenge sent to `signChallenge` is a hash and users is unable to see the transaction actions in the JoyID signing request page. As a remedy, the PoC will show how the hash is derived. Once JoyID has the native support of the Co-Build protocol, the signing page will show the transaction actions. ## Transaction Building The JoyID DAO Lock PoC adopts the Co-Build transaction building protocol. The protocol stores all the information required to build transactions in [`BuildingPacket`](https://github.com/cryptape/ckb-transaction-cobuild-poc/blob/main/schemas/basic.mol) The `ScriptInfo` for JoyID DAO Lock: ``` name: JoyID DAO Lock url: TBD script_hash: Deployment Dependent schema: See Action.data scehma above message_type: JoyIDDAOData ``` ## Future Works - Supports JoyID sub keys. - Allow users to delegate the withdraw to service providers. - User can schedule a withdraw in a future time. - Service providers can initiate the scheduled withdraws for users without interaction. - Service providers can complete the phase 2 withdraw for users without interaction. - Locked cell ownership transfer. - Allow users to transfer the ownership of locked DAO cells to others. Features limited by JoyID - The PoC uses the different CKB address, because it's impossible to sign any transaction in JoyID. - The signing request page does not show the transaction actions. A workaround is generating a JSON string as the challenge to include the skeleton hash and transaction actions.