Block Header

The to-be-signed content includes the Previous, Sequence and Records elements.

Block Key Computation

U4570-01 The block-key is computed as the digest of the DER encoded block, including the Previous, Sequence and Records elements.

Manifest

U5062-23 The manifest-record occurs in the first account block.

The same key-pair can be used for multiple accounts using a different account-selector for each account.

Transfer

U5074-02 The transfer-record stores information about outgoing voucher transactions.

Receive

The receive-record captures incoming voucher transactions.

Encoding

R5074-04 The signature is computed on the SHA-256 digest of to-be-signed.

The signature verify-data is computed using RSA-SHA256 using PKCS#1 padding including the block-key and possibly other elements, depending on the signature-type, as described below.

TBSData ::= SEQUENCE { kind INTEGER, blockKey OCTET STRING, -- optional elements -- accountSelector [0] IMPLICIT OCTET STRING, digestOfVouchers [1] IMPLICIT OCTET STRING, -- trailer -- timestamp GeneralizedTime, signerKeyIdentifier OCTET STRING, }

Validator

U5074-08 The validation procedure ensures that sufficient funds exist to perform the requested transfer.

The input to the validator includes at least one block containing a transfer-record. The block must be preceeded by any receive-blocks incorporated into the account-book after the first-block or the last transfer-block.

The previous-block-key of the first block supplied to the validation procedure must refer to the first-block or the last-transfer-block.

As the result of a successful validation, the validator creates a validator-signature and returns it the requestor.

The signature computiation must include the block-key of the new transfer-block, the last-transfer-block-key and the digest-of-balance-element.

Minter

The minter performs two complementary tasks: the mint-procedure creates a new coin associated with a previously validated transfer-block, while the melt-procedure consumes a previously created coin into the receive-block of the receiving account.

The minter interacts with the consensus-system to store account-registration and coin-transaction information.

Minter transactions are repeatable. The requestor shall repeat the request with the same parameters in case of a network problem.

Deposit Account

The balance of a normal account is not allowed to go below zero with any transaction.

Bailment Accounts

R5082-28 In contrast to a normal account, a bailment-account is not allowed to exceed a balance of zero.

The negative balance of a bailment account shall correspond to the balance of the associated physical account.

Transfers outgoing from bailment-accounts correspond to incomes on the physical account.

Receives incoming to a bailment-account correspond to a withdrawal of physical funds.

Sender

The sender shall prepare and validate a new transfer-block.

R5065-12 The sender shall allocate a coin-secret and derive the transfer-protection-key from it.

U5075-01 The sender shall compute the sender-coin-token from the sender-coin-secret, the next block-key and the transfer-amount.

U5089-01 The sender shall compose a coin-payload including the transfer-amount.

R5089-02 The sender shall encrypt transfer-data using the transfer-protection-key to generate the protected-coin-payload data element.

The sender shall persist request data, before sending the request to the minter; the request MUST be repeated in case of network failure.

The sender shall select a minter randomly and send the mint-request including the transfer-block-key, the protected-coin-payload, account and validator signatures.

As result of a successful MINT operation, the sender receives a minter-token from the minter.

Minter

The minter shall generate a random minter-token for the new coin. It shall associate the protected transfer-data with it in the consensus-system.

The minter shall update the account-state to reflect the transfer. It shall store transfer-data with the account-state.

The minter shall create a minter-coin signature.

The minter shall return the minter-coin signature and the coin-consensus-key to the sender.

Sender

After receiving the mint-response, the sender shall extract the minter-token and minter-coin signature and persist the block into the account-book.

U5077-04 The sender computes the coin-transfer-token from the coin-secret and the minter-token.

Depending on the use-case, there are two possible flows for transferring the coin-token:

Account Identifier

R5075-09 The account-identifier is computed as the digest of the following structure:

AccountIdentifierToBeDigested ::= {  schemeURI UTF8String,  keyIdentifier OCTET STRING,  selector OCTET STRING }

Amount

The amount-element contains one or more simple-amount-elements, ordered by voucher-unit for canonical representation.

Amount ::= SET OF SimpleAmount

Bailment Declaration

R5082-28 The bailment-declaration MUST be present in the manifest-record of bailment-accounts.

BailmentDeclaration ::= SEQUENCE {  accountNumber UTF8String,  accountOwner UTF8String,  institute [0] UTF8String }

Block

U5074-10 ASN.1 representation of account block.

Block ::= SEQUENCE {  sequence INTEGER,  previousBlockKey OCTET STRING OPTIONAL,  records SEQUENCE OF EncodedRecord,  signatures [0] EXPLICIT OPTIONAL SEQUENCE OF Signature  attributes [1] EXPLICIT OPTIONAL SEQUENCE OF BlockAttribute }

CoinPayload

U5077-02 Information stored in the consensus system on behalf of a coin.

CoinPayload ::= SEQUENCE { references [0] EXPLICIT SET OF ReferenceElement OPTIONAL, vouchers [1] EXPLICIT Amount, }

CoinTransferToken

U5077-04 The encoded coin-transfer element must be transmitted from sender to receiver directly.

CoinTransferToken ::= SEQUENCE {  version INTEGER DEFAULT(0),  sendersecret OCTET STRING,  mintertoken OCTET STRING }

CredentialData

CredentialData ::= SEQUENCE {  keyIdentifier [0] IMPLICT OCTET STRING OPTIONAL,  encodedX509Certificate [1] IMPLICIT OCTET STRING OPTIONAL }

ManifestRecord

U5062-23 Manifest Record ASN.1 Syntax.

ManifestRecord ::= SEQUENCE {  publicKey CredentialData,  selector OCTET STRING,  manifestItems [0] OPTIONAL SEQUENCE OF CHOICE {   bailment BailmentDeclaration  } }

For bailment-accounts, manifest-items shall contain exactly one bailment-declaration.

Record

A record wrapper is used to keep the protocol open for custom content.

EncodedRecord ::= SEQUENCE {  type RecordType,  content COICE {   rawcontent OCTET STRING,   manifest ManifestRecord,   receive ReceiveRecord,   transfer TransferRecord } }

RecordType ::= CHOICE {   numtype BasicRecordType,   oidtype OBJECT IDENTIFIER }

ReferenceElement

U5089-07 Reference information to be included into a record.

ReferenceElement ::= SEQUENCE {  typeID ReferenceTypeID,  content ReferenceContent OPTIONAL }

The type of reference can be given by an URI or an object-identifier:

ReferenceTypeID ::= CHOICE {  uri IA5String,  oid OBJECT IDENTIFIER }

The content can be a string or binary content.

ReferenceContent ::= CHOICE {  text UTF8String,  binary OCTET STRING }

The following are TypeID currently in use:

ReceiveRecord

Represents an incoming transaction.

ReceiveRecord ::= SEQUENCE {  references [0] EXPLICIT SET OF ReferenceElement OPTIONAL,  vouchers Amount }

Signature

U4565-04 The signature element is DER encoded according to the following syntax:

Signature ::= SEQUENCE {  kind INTEGER,  timestamp GeneralizedTime,  signerKey CredentialData,  accountSelector [0] IMPLICIT OCTET STRING OPTIONAL,  verifyData OCTET STRING }

TransferMessage

U4596-01 Full transfer information message.

TransferMessage ::= SEQUENCE {  coin OCTET STRING,  references [0] SET OF ReferenceElement OPTIONAL,  vouchers [1] Amount OPTIONAL,  senderBlockKey [2] OCTET STRING OPTIONAL }

TransferRecord

Represents an outgoing transaction.

TransferRecord ::= SEQUENCE {  references [0] EXPLICIT SET OF ReferenceElement OPTIONAL,  vouchers Amount }