Account Creation

Create a new Ouronet Account

A Client may create a Standard Ouronet Account, or a Smart Ouronet Account, once a Demiourgos Codex has been created. Its management is only possible if its Public Keys are present in the Demiourgos Codex.

Creating a Standard Ouronet Account requires:

1. An Account string, this is automatically derived from the Seed Words

2. A Guard (more on this below)

3. A Kadena Account fueled with 10 KDA

4. A string with the Public Key of the Ouronet Account (also derived from Seed Words)

So while 1) and 4) are derived from the Ouronet Seed Words, a Guard is needed and an existing Kadena Account, to create a Standard Ouronet Account

Pact Guard

A Pact Guard is a mechanism used to enforce authorization schemes within smart contracts. It acts as a predicate function over some environment, allowing for a pass-fail operation through the <enforce-guard> function. There are several types of Guards

• KEYSET Guards: These are the traditional guards in Pact, specifying a list of keys and a predicate to verify how many keys are needed to sign a Transactions Enforcement is executed using <enforce-keyset>

• KEYSET REFERENCE Guards: These Guards allow you to use a defined keyset using a string, making it easier to store and manage keyset within an environment Useful for integrating environment keysets with concrete keysets and other guards

• CAPABILITY Guards These Guards are created from capabilities using the <create-capability-guard> function. They enforce the rules defined by a capability, allowing utilization of fine-grained control provided by capabilities as a guard. This means one can enforce complex logic and conditions encapsulated in a capability as a guard.

• USER Guards These Guards are essentially custom guards created from user-defined predicate functions, or simply put functions made guards. Allows for implementation of specific logic that can't be captured by any other guard types, helpful in designing complex access control rules tailored to one's needs.

So while an Ouronet Account, can have any guard Type, when creating it, only the first two Guard Types are supported by the UI. If a Capability of User Guard is needed for any Ouronet Account, this can be changed later, using its Rotate Function.

KEYSET Guards

The Client creating an Ouronet Account, has the ability to create it using a KEYSET Guard. This is how a Keyset can be defined from a Public Key, in the environment of the TX.

{
  "ks": {
    "pred": "keys-all",
    "keys": [
      "f961b783adca6c668f3f663610d8e0906318211867beedd80cbfd5fa686ee3c1"
    ]
  }
}

which can then be used as a guard, whenever a guard is needed in any give function, as exemplified below with the <coin.transfer-create> function existing in the coin module (Kadena's Token Module):

(coin.transfer-create 
    "k:bfcfdd740857ab6be8d6acce80f9fef6c0ad99e46c9b6e2dc24e0fe2850bede9" 
    "k:f961b783adca6c668f3f663610d8e0906318211867beedd80cbfd5fa686ee3c1" 
    (read-keyset "ks") 
    21.58739
)

KEYSET REFERENCE Guards

In this case, the Key exists deployed on a given Kadena chain, in a given namespace, and it is referenced as a guard. This means the Key must first be installed, to exist, to be referenced as a guard. This is how a key is installed:

First, in a similar manner, the key must first be defined in the TX environment:

{
    "dh_master-keyset": {
        "keys": [
            "35d7f82a7754d10fc1128d199aadb51cb1461f0eb52f4fa89790a44434f12ed8",
            "428a0ed942d266d84e6bf995d1612c009777eda858e92c0c9bc3ef8932d4e44d"
        ],
        "pred": "keys-any"
    }
}

Then, a transaction with the following code, must be executed, to "save it on the blockchain".

(define-keyset 
    "n_7d40ccda457e374d8eb07b658fd38c282c545038.BossKey" 
    (read-keyset "dh_master-keyset")
)

Now this Keyset is defined on the n_7d40ccda457e374d8eb07b658fd38c282c545038 Namespace, and can be used as follows, whenever a guard is needed:

(coin.transfer-create 
    "k:bfcfdd740857ab6be8d6acce80f9fef6c0ad99e46c9b6e2dc24e0fe2850bede9" 
    "k:f961b783adca6c668f3f663610d8e0906318211867beedd80cbfd5fa686ee3c1" 
    (keyset-ref-guard "n_7d40ccda457e374d8eb07b658fd38c282c545038.BossKey") 
    21.58739
)

Do note that in this case, a Custom Key was created composed of two Public Keys, and the Key would be verified, if any of the two Keys is used for signing.

What this means

In both of these cases, as one was able to notice, an environment load must be used to either use a key directly on the go, or to first save it on the blockchain for later referencing. But in each case, a Kadena Public Key was required:

"35d7f82a7754d10fc1128d199aadb51cb1461f0eb52f4fa89790a44434f12ed8"

A public Key of this type, via a <keys-all> predicate, is also what is by default used to create a so called k: Kadena Account, the k: Kadena Account being tied to this specific Public Key, looking like this:

"k:35d7f82a7754d10fc1128d199aadb51cb1461f0eb52f4fa89790a44434f12ed8"

What is needed for a proper operation of an Ouronet Account, is that the Public Key used to create the Guard of the Ouronet Account, to be different from the Guard of the Kadena Account used at 4) to define the Ouronet Account. This means, that 2 Different Public Keys are needed for creating an Ouronet Account, to ensure proper functioning.

When Rotating the Ouronet Account Guard, and/or Rotating the Kadena Account Associated with the Ouronet Account, proper care must be observed, such that the Ouronet Guard, and Kadena Accounts Guard, still remain based on different Public Keys (or Public Key combinations)