ASSETS

According to the Kuknos whitepaper, asset is any property or rights and obligations therein, whether movable and immovable or tangible and intangible, that tokenization and network trading are possible. Tokenization is a process that under the supervision of the anchor the issuer creates token.
Token in kuknos network is certificate token and asset token. Certificate token is a digital certificate issued by an issuer indicating ownership of the token in whole or in part of an asset and asset token is an Independent-owned tokens, whose back-end assets are collateralized and guaranteed by the anchor or issuer for liquidity, and token trading on the Kuknos network does not necessarily mean back-end trading.
The Kuknos distributed network can be used to track, hold, and transfer any type of asset issued in network : Paymon, SKYC, ABPARS and other tokens of value. Any asset on the network can be traded and exchanged with any other.
Other than Paymons (see below), all assets have

  • Asset code: e.g., SKYC, ABPARS
    – Issuer: the account that created the asset Issuer is a real and legal person under the supervision of an anchor, who can issue Token. The anchor publishes issuer specific, and specific features of the issued token to the public.
    – Flags : represents the criteria by which accounts will be allowed to hold assets ,possible flags are the following :

    • Auth_required: to have the asset ,you need the issuer of assets allows with your trustline and until it do so ,you can’t hold or trade the asset.
    • Auth_revocable: asset issuer can revoke its permission, note that as soon as issuer revoked its trust to specific account , the account is not able to move the asset and the asset will become frozen in that account.
    • Auth_immutable: issuer of the asset is not able to change its flags.

TRUSTLINES

When you hold assets in Kuknos, you’re actually holding credit from a particular issuer. The issuer has agreed that it will trade you its credit on the Kuknos network for the corresponding asset–e.g., precious metal–outside of Kuknos. Let’s say that Ali issues oranges as credit on the network. If you hold orange credits, you and Ali have an agreement based on trust, or a trustline: you both agree that when you give Ali an orange credit, he gives you an orange.
When you hold an asset, you must trust the issuer to properly redeem its credit. Since users of Kuknos will not want to trust just any issuer, accounts must explicitly trust an issuing account before they’re able to hold the issuer’s credit. In the example above, you must explicitly trust Ali before you can hold orange credits.
To trust an issuing account, you create a trustline. Trustlines are entries that persist in the Kuknos ledger. They track the limit for which your account trusts the issuing account and the amount of credit from the issuing account that your account currently holds.
Each trustline also tracks the liabilities for the corresponding account and asset. Buying liabilities equal the total amount of this asset offered to buy aggregated over all offers owned by this account, and selling liabilities equal the total amount of this asset offered to sell aggregated over all offers owned by this account. A trustline must always have balance sufficiently large to satisfy its selling liabilities, and a balance sufficiently below its limit to accommodate its buying liabilities.
To be succinct, by trusting to and asset issued by an account id , you verify that you have read whitepaper of the token and you verify that it is a valid , legal asset .

PAYMONS (PMN)

Paymons (PMN) are the native currency of the Kuknos network. Paymon is the only asset type that can be used on the Kuknos network that doesn’t require an issuer or a trustline.
Any account can hold Paymons. You can trade Paymons for other assets in the network. Each trustline to other tokens is an operation and costs 0.005 PMN (50000 penutes)
Paymon is a token which represents ownership for a gold-backed asset, each paymon is equal to 0.001 gram 995 gold

ANCHORS: ISSUING ASSETS

A Kuknos anchor is a trusted entity on the Kuknos network that is permitted to hold issuers’ deposits and issue credit for those deposits . anchors act as a bridge between asset issuers, we use asset issuer or issuer interchangeably.
If someone or some organization wants to tokenize its assets, whether for collateralization or any of security offerings. it refers to an anchor and through the anchor does its offering.
Ultimately, it’s up to the issuer to set the asset code. By convention, however, currencies should be represented by the appropriate ISO 4217 code. For your orange, goat, favor, or coin, you’re on your own–invent an appropriate code!
Currently there are two supported formats for asset codes.

ASSET FIELDS

Alphanumeric 4-character maximum

Any characters from the set [A-Z][0-9] are allowed. The code can be shorter than 4 characters, but the trailing characters must all be empty.

Alphanumeric 12-character maximum

Any characters from the set [A-Z][0-9] are allowed. The code can be any number of characters from 5 to 12, but the trailing characters must all be empty.

Controlling asset holders

By default, anyone can create a trustline with an asset issuer to accept an asset. However, as an anchor, you can explicitly authorize and revoke user access to your asset by enabling the following flags on your issuing account.

  • AUTHORIZATION REQUIRED: with this setting, the asset issuer must approve anyone who wants to hold its asset, allowing it to control who its customers are. Approving is done by the issuer by setting the Authorize flag of an existing trustline to true with the Allow Trust operation.
  • AUTHORIZATION REVOCABLE: with this setting, the asset issuer can set Authorize flag of existing trustline to false with the Allow Trust operation, to freeze the asset held by another account. When an asset is frozen for a particular account, that account can’t transfer the asset to any other account, not even back to the anchor. This setting allows the issuing account to revoke assets that it accidentally issued or that were obtained improperly. To use this setting, AUTHORIZATION REQUIRED must also be enabled.

**Example flow for an account with AUTHORIZATION REQUIRED and AUTHORIZATION REVOCABLE enabled:

  1. User decides he/she wants to accept an asset
  2. User opens a trust line with this asset’s issuing account
  3. Issuer authorizes the user’s trustline
  4. User can accept and send the asset to whomever else has a trustline open with the issuer
  5. Issuer wants to freeze user’s access to asset
  6. Issuer deauthorizes user’s trustline
  7. User cannot send or accept this asset

An alternative flow: note it is possible to set these flags later. Maybe you originally allow anyone to open a trustline but later realize this was not a great idea. After issuing this asset, you can then set both of the above flags. At this point, everyone with an open trustline retains their authorized status, however you can now revoke trust (assuming you have not adjusted your master key weight and/or account thresholds) .

Note: when issuers issue assets, they often wish to limit the supply of tokens in circulation. It is still possible to create this limited supply and maintain the ability to authorize and revoke because the Allow Trust operation is low threshold while the Set Options and Payment operations are high/medium threshold.

Ensuring asset holders they won’t be revoked: the above functionalities are great for asset issuers who wish to control who can and cannot hold/transact their asset. However, what if I am an asset holder and I am worried that an issuer may freeze the assets I hold? To instill trust in potential asset holders, the issuing account can enable the following flag:

  • AUTHORIZATION IMMUTABLE: with this setting, none of the authorization flags can be set and the account can never be deleted.

AMOUNT PRECISION AND REPRESENTATION

Each asset amount is encoded as a signed 64-bit integer in the XDR structures. An asset amount unit is scaled down by a factor of ten million (10,000,000) to arrive at the native 64-bit integer representation. For example, the integer amount value 25,123,456 equals 2.5123456 units of the asset. This scaling allows for seven decimal places of precision in human-friendly amount units.
The smallest non-zero amount unit is 0.0000001 (one ten-millionth) represented as an integer value of one. The largest amount unit possible is ((2^63)-1)/(10^7) (derived from max int64 scaled down) which is 922,337,203,685.4775807.
The numbers are represented as int64s. Amount values are stored as only signed integers to avoid bugs that arise from mixing signed and unsigned integers.