Testnet Theodoric-II Scope

Overview

Theodoric-II is the testnet of dchain.

Recap of Theodoric-I

In Theodoric-I, we tested the following features.

Theodoric-II Scope

Building on the SSI-enabled validator onboarding, 2 layers governance and decentralisable verifiable credentials issuance, Theodoric-II will focus on the following features:

• Tokenomics: The burning and minting of DTs is designed to provide supported applications with a predictable cost and to provide DT holders with security lending rewards that aligns with the success of the network.

  • Minting: The rewards schedule is designed such that DT reaches a maximum supply of 100 billions DTs. The testnet will start wit 80 billions DTs and simulate an accelerated schedule for unlock, minting and reward reduction.
  • ** Burning**: The burning of DTs will be tested by platformD application.

• Abstract Account: Allow users to sign up and complete onchain transactions with webauthn.

• Staking: Using abstract account to complete staking related transations

• Governance: Voting in the governance on Dchain. In order to vote, requires staking DTs AND valid verifiable presentation as part of the voting transaction. Vaildators have the voting power proportional to their own staked DTs only, delegated DTs can only be used to vote by the delegators themselves.

• platformD initial end-to-end flow: The initial end-to-end flow of platformD application will be tested on Theodoric-II. This includes burning of DTs as part of the utilities fees of using modules on Dchain.

Testnet users onboarding

Initial account creation (pre-genesis)

sequenceDiagram
    autonumber
    actor dh as DT holder

    participant kc as Keycloak
    participant be as platformD Backend
    participant Dchain

    dh ->> kc: create new account (with webauthn)
    kc ->> be: event hook (account created)
    be ->> be: predict proxy contract address
    be ->> kc: update user with contract address
    note over be: batch create vesting <br /> create proxy with authenticator contracts

1. In the testnet we will allow user to just go to demo.platformd.io and create a new account. We can do this by allowing self-registration in keycloak. We will ask for email and require webauthn registration, we can ask for password if we want, but must have webauthn. See the setting of the keycloak realm for just webauthn and no password.

2. When the account is created, we want to have a hook to call the backend to predict the proxy contract address. It looks like some sort of java event listener is needed. I asked grok and I think its pretty standard. Here is an example I found.

3. The backend that gets called will predict the proxy contract address. This actually requires a few things.

   • We need to assume an "platformD admin" dchain address that will deploy the proxy contract, a salt (which we need to store to make sure we use the same one when we create the proxy contract), and I think we also need to have the code id and also the message? (check out Instantiate2 logic, I think we can use fix_msg option to make it independent of instantiation message?), see x/abstractaccount/keeper/msg_server.go l:75

4. Update keycloak with the new address. We want the frontend to have such address in the jwk to pull balances in the future.

@Andrew: here are some previous work that you should checkout before implementation:

1. The backend can in fact get the credentialData from Keycloak user data. I did it in rust here
2. This credentialData should be the correct data to be used in the proxy authenticator, some details on this:
   • As a reference ONLY (vectis has changed significantly since we wrote this webapp) - We directly used the browser to create the credential here, not keycloak. but insteaof using this.navigator.credentials.create, I expect keycloak will do all that and store the AuthenticatorAttestationResponse in the credentialData field of the user. Keycloak should be storing the same data the type from MDN Reference.
   • You can see the end to end flow of using the passkey-cli to create a credential and then use that to sign a challenge - the challenge being the hash of the bytes from the cosmos transaction in the test here