Accounts are the central data structure in Kuknos. Accounts are identified by a public key and saved in the ledger.
Everything else in the ledger, such as offers or trustlines, are owned by a particular account.
Accounts are created with the Create Account operation.
Account access is controlled by public/private key cryptography. For an account to perform a transaction–e.g., make a
payment–the transaction must be signed by the private key that corresponds to that account’s public key. You can also
set up more complicated multi-signature schemes for authorizing transactions on an account.


Accounts have the following fields:

Account ID
The public key that was first used to create the account. You can replace the key used for signing the account’s transactions with a different public key, but the original account ID will always be used to identify the account.

This field represents assets hold by the account, from now on asset and token in this guide will be used interchangeably ,along with their amount. It’s worth mentioning that user trusted assets is shown here even though user just have trusted to the asset and if user does not own from that asset ,its balance will be 0.

Sequence number
The current transaction sequence number of the account. This number starts equal to the ledger number at which the account was created.

Number of subentries
Number of other entries the account owns. This number is used to calculate the account’s minimum balance.

Currently there are three flags, used by issuers of assets.

  • Authorization required (0x1): Requires the issuing account to give other accounts permission before they can hold the issuing account’s credit.
  • Authorization revocable (0x2): Allows the issuing account to revoke its credit held by other accounts.
  • Authorization immutable (0x4): If this is set then none of the authorization flags can be set and the account can never be deleted.

Home domain
Accounts may optionally have a home domain specified. This allows an account to programmatically specify where is the main federation provider for that account .

Operations have varying levels of access. This field specifies thresholds for low-, medium-, and high-access levels, as well as the weight of the master key. For more info, see multi-sig.

Used for multi-sig. This field lists other public keys and their weights, which can be used to authorize transactions for this account.

Starting in protocol version 10, 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.