Skip to main content

Economic flows

This document aims to describe the Dizme Economic Flows, which includes all interactions between all participating entities and the foundation. Especially focusing on credential billing and reports.

References

Generalities

Dizme Foundation is a distributed collaborative platform for secure credentials exchange using Self Sovereign Identity.

There are 4 main parts involved: Credential Issuer (next. Issuer), Credential Verifier (next. Verifier), Credential Owner (next. Owner) and Dizme Foundation which implicitly participates in all processes.

SSI Model

The fundamental flow is as follows: Issuer emits a credential, this one should be any kind of asset, an Identity Card or a Passport for example, which is stored in the Owner's wallet. Once this credential, or its part, is requested by the Verifier, imagine a bank needs an ID for a loan, Owner can provide it. Securely, without reconfirmation or additional validation from the Issuer.

Issuer and Verifier are software components, they can be deployed either in Dizme Cloud infrastructure (namely in the house) or on-premise in the client's data centre. The owner is represented as a mobile application.

Onboarding process

When an organization joins the foundation it should set up 2 logical components: SSI Agent and Accounting Agent.

The first one is responsible for credential exchange, verification and issuing and is far away from the scope of this document. The second one is Accounting Agent, which contains all the necessary software components to interact with the Algorand Blockchain and Foundation Economic Flows.

Fig.1: Blockchain interactions Fig.1: Blockchain interactions

Onboarding in Dizme Economics has the following steps:

  • Algorand Wallet Creation - which means generating Wallet Private Key
  • Algorand Wallet Initialization - transfer of a minimum sum of Algorands to newly created wallet from Foundation
  • Asset opt-in - creating a special transaction on the blockchain which indicates the will to be part of Dizme Tokens
  • Signing Smart Contract - signing a special contract which allows Foundation to move token from and to Algorand Wallet

All these steps are performed automatically and doesn't need customer interactions.

Credential Issuing Process and Pricing

The issuer is a crucial player in the Dizme Foundation, responsible for managing the economic flow of credentials. As part of this responsibility, it determines the price of credentials in Dizme tokens when issuing them.

In the economic model of the Dizme Foundation, the scheme entity is integrated with a default price in Dizme Coin, which is predetermined by the foundation. This default price is meant to be an average value on the market for the particular credential.

To ensure transparency and accessibility, the Dizme Foundation regularly publishes a price list of all credentials and schemas. This list includes the default prices for all schemas, as well as the prices set by the issuers for each credential. Each version of the price list is dated with a version number, and all participants in the foundation have access to the current, previous and next versions.

pricing_update_flow.png Fig.2 Pricing update flow

Issuers, as said before, are given the freedom to set their own prices for their credentials, but the Dizme Foundation reserves the right to discuss any prices that may pose a risk to the foundation's economic stability.

When an issuer updates the price of their credential, the change is not immediately applied. Instead, the update is added to a waitlist and will be published in the next version of the price list. A new version of the price list is published daily at 00:00 UTC. The waitlist for the next version of the price list is closed one hour before the update, at 23:00 UTC. If there are any updates after the waitlist closure, they will be added to the waitlist for the following day's update.

Credential Verification Process

Foundation Economic flows are hardly connected to the credential verification process; each time credential is verified, the issuer who has emitted that credential is paid by Diz tokens.

Verification Process Fig.3 Verification process

In Fig.3 there is a simple but complete verification process in terms of economic interaction. More specifically, when the verifier receives requested data from the owner, Verifier Agent will send metadata about received credentials to the foundation. The same metadata will be delivered to the foundation from the owner to be cross-checked.

The foundation receives metadata from the verifier and using the current pricelist will force the verifier to pay the foundation. This transaction is a real-time transaction and occurs at each credential verification.

Another flow is Nightly Payments, which are essentially aggregations of all transfers which must be delivered to the Issuer in one, single transaction. This transaction will contain the sum of all credential gains during a previous 24h time period.

Credential Billing

Credential Billing is a process of defining credential verification prices. SSI proof requests can contain zero or more revealed credentials, zero or more unrevealed credentials and zero or more self-attested credentials.

The billing formula is applied for all credentials where the issuer and verifier are different organizations.

A general formula of Total Credential Price is the following:

Price Formula

Where:

  • CD - Credential Price (without fee)
  • IP - Issuer requested Price
  • TA - Total Attribute Count
  • URA - Used Attributed count
  • SA - Self Attested attribute count
  • C - Self Attested Constant
  • ceil - round up

The first sum in the formula is the partial revealed credential price, which is the sum of all credentials used divided by the number of attributes of credential times actually used attributes. Before sum, this value is ceiled.

The second part of the formula is self-attested attributes price, essentially the number of attributes if multiplied by C which is the self-attested constant.

The last part is the unrevealed credentials price. For each unrevealed credential foundation will bill the verifier for ⅓ of the total credential price.

Once the credential price is defined, Dizme Fee is applied according to the next formula:

Fee Formula

Which means that Dizme Fee is the sum of credential prices divided by 25 ceiled but not more than 5.

The total price hence will be the sum of FEE and CD:

Totals formula

Self-payment

The corner case of self-payment, is when some specific credential’s issuer is the same as the verifier one. In this case, partial credential prices will be considered only for fee calculation and nextly will be set to 0.

Example 1

Let’s assume that there are 3 credentials:

Credential Name Attributes Price Issuer Organization
IDDocument [‘name’, ‘surname’, ‘birth’] 100 A
L1Bio [‘selfie_img’] 250 B
Diploma [‘vote’] 50 B

Verifier is Organization C

Proof template requires:

Revealed attributes [‘name’, ‘surname’] of credential IDDocument of organization A
Revealed attributes [‘self_img’] of L1Bio of organization A
Unrevealed attribute [‘vote’] of Diploma of organization B
Self-attested attribute [‘eye_color’]

Hence:

  • 67 = ceil(100/3*2)
  • 250 = ceil(250/1*1)
  • 17 = ceil(50/3)
  • 3 = 1*3
    • C is set to 3 and there is only one self-attested attribute

The total sum is 337

Dizme fee:

  • 5 = min(ceil(337/25), 5)

Total price which will be billed is 337+5 = 342 Diz

Example 2 with Self-Payment

Let’s assume that there are 2 credentials from the previous example:

Credential Name Attributes Price Issuer Organization
IDDocument [‘name’, ‘surname’, ‘birth’] 100 A
L1Bio [‘selfie_img’] 250 B

Verifier is Organization B

Proof template requires:

Revealed attributes [‘name’, ‘surname’] of credential IDDocument of organization A
Revealed attributes [‘self_img’] of L1Bio of organization A

Hence:

  • 67 = ceil(100/3*2)
  • 250 = ceil(250/1*1)

Total sum is 317

Dizme fee:

  • 5 = min(ceil(317/25), 5)

Once the fee is calculated, there is a self-payment verification, means that in this example verifier is the organization B, L1Bio is of this organization so the price of L1Bio attribute must be set to 0. In other words, the price of the L1Bio attributes, 250, must be subtracted from the Total sum:

The total price which will be billed: 317 - 250 + 5 = 72 Diz

Reports

All described above transactions, from the verifier to the foundation and from foundation to issuer have a descriptive note.

Verifier Foundation flow

Verifier Foundation flow aka real-time transaction is the billing transaction for verification. On Algorand blockchain, the note is of the following format:

{
  "dg": "e4b084fa4bdbf5c1b72364fe48e04976ca258fb294ee2dd2d26b4cc4bc3981ce",
  "sg": "anruepxsbehujxjvlgtkljfeyygpddjebg",
  "td": "1aea3157-41ea-404e-9cad-0f4a2c154e07",
  "vn": "v.1",
  "report": "https://reveal-sv.dizme.io/v.1/FqtdLvcM2i4Q7Ewd8Uf8FJ/2023/01/16/vf/f8a560c0c82539b7fc353ddc6194675a4239df70f440b812952308c4d8a0b214.json",
  "hash": "f8a560c0c82539b7fc353ddc6194675a4239df70f440b812952308c4d8a0b214"
}
Key Description
dg Digest of transaction
sg Metadata Signature performed by dizme agent
td Transaction ID, generated on customer organization level
vn Version
report Report link
hash SHA256 hash of report 
{
  "timestamp": 1673889536,
  "report": [
    {
      "cd": "P6UvpU451XA5p8Dx6zsuUu:3:CL:38369:L0_BIO#OBS",
      "ca": [
        "selfie_img",
        "timestamp"
      ],
      "pr": 100,
      "bpr": 100,
      "self_pay": false,
      "unrevealed": false
    },
    {
      "cd": "P6UvpU451XA5p8Dx6zsuUu:3:CL:57733:test_schema_001",
      "ca": [
        "surname"
      ],
      "pr": 50,
      "bpr": 50,
      "self_pay": false,
      "unrevealed": false
    },
    {
      "cd": "FqtdLvcM2i4Q7Ewd8Uf8FJ:3:CL:38178:test",
      "ca": [
        "type"
      ],
      "pr": 0,
      "bpr": 10,
      "self_pay": true,
      "unrevealed": false
    }
  ],
  "meta": {
    "vn": "v.1",
    "fee": 5,
    "dg": "e4b084fa4bdbf5c1b72364fe48e04976ca258fb294ee2dd2d26b4cc4bc3981ce",
    "sg": "anruepxsbehujxjvlgtkljfeyygpddjebg",
    "pi": "email-openid-fa",
    "pv": 20230116,
    "sa_amt": 2,
    "td": "1aea3157-41ea-404e-9cad-0f4a2c154e07",
    "dids": [
      "P6UvpU451XA5p8Dx6zsuUu",
      "P6UvpU451XA5p8Dx6zsuUu",
      "FqtdLvcM2i4Q7Ewd8Uf8FJ",
      "P6UvpU451XA5p8Dx6zsuUu"
    ]
  }
}

Values on this json are purely indicative

Key Description
timestamp Unix epoch timestamp
report Array of all credentials used in template
cd Credential Definition
ca Array of credential attributes
pr Credential Partial Price
bpr Credential Partial Price Used for fee calculation
self_pay Set to True if verifier and issuer is the same organization
unrevealed Set to True if this is an unrevealed attribute
meta Additional meta attributes
pi Proof template name
fee Dizme fee
pv Price version
sa_amt Price for self attested attributes
dids Array of DIDs of issuers

Foundation Issuer flow

Foundation Issuer flow, aka batch, is executed by the foundation overnight and aggregates all gains of the issuer. The report will include all available information about credential usage.

Algorand transaction note contains only the report parameters.

The report is formatted as follows:

{
  "timestamp": 1673953907,
  "report": [
    {
      "cd": "FqtdLvcM2i4Q7Ewd8Uf8FJ:3:CL:38178:test",
      "ca": [
        "type"
      ],
      "pr": 0,
      "bpr": 100,
      "self_pay": true,
      "unrevealed": false
    },
    {
      "cd": "FqtdLvcM2i4Q7Ewd8Uf8FJ:3:CL:45993:L1_DOC",
      "ca": [
        "type"
      ],
      "pr": 34,
      "bpr": 34,
      "self_pay": false,
      "unrevealed": true
    }
],
  "meta": {
    "vn": "v.1",
    "did": "FqtdLvcM2i4Q7Ewd8Uf8FJ",
    "total": 34,
    "date": "2023/01/16"
  }
}

Values on this json are purely indicative

Key Description
timestamp Unix epoch timestamp
report Array of all credentials
cd Credential Definition
ca Array of credential attributes
pr Credential Partial Price
bpr Credential Partial Price Used for fee calculation
self_pay Set to True if verifier and issuer is the same organization
unrevealed Set to True if this is an unrevealed attribute
meta Additional meta attributes
total Total gain
vn Version
did Issuer did
date Date of processing
Back to top