Prometheum Blockchain

An Architecture for Blockchain Securities

This paper sets out the technology Prometheum is building for blockchain securities. This specifically includes the Prometheum Blockchain architecture and Smart Security Token smart contract layer.

Prometheum is also building out the commercial infrastructure for the issuance, custody, trading and use of blockchain securities in the US and beyond. Prometheum’s Blockchain is the fundamental building block for this entire blockchain securities ecosystem. This architecture lays out how the Prometheum Blockchain system works.

A full reading of this document assumes the reader has some familiarity with blockchain concepts as well as typical multi-system commercial/technical architectures, but the ’in brief’ and ‘glossary’ boxes provide non-technical summaries and key terms.

Introduction

The Prometheum Blockchain provides the basis for regulated (“Core” blockchain) transfers of Smart Security Tokens (SSTs)^TM as well as use by Dapp creators and users on the “Utility” blockchain. See ‘Multi Chain Design’ for more information about the split chain model.

The Prometheum Blockchain does not suppose or attempt to replace the traditional securities infrastructure at Clearing Firms, Broker-Dealers or Alternative Trading Systems. It is intended to work alongside existing financial infrastructure to provide a mechanism by which SSTs (Prometheum’s name for blockchain securities) can be used in a regulated environment (e.g. issuance, investment, secondary trading) as well as in token scenarios (e.g. in distributed applications – Dapps – deployed to a public blockchain).

The Prometheum Blockchain runs as two or more linked public blockchains with a permissioned accounts model exclusively on the Core chain and open-model availability on the Utility chain. As Ember (Prometheum’s own SST) is required for transaction fees, all parties interacting with a Prometheum Blockchain Core chain must be able to create an account with a Broker-Dealer and pass required due diligence and AML/KYC requirements.

What are Tokens?

Tokens are typically considered to be structures and data in a smart contract on a public blockchain. Normally tokens are created by a contract controlled by a single entity but are distributed to many other entities/individuals who can then use them within the confines of the smart contract that created them. Many tokens are created based on open standards that allow for the same tools to be used to work with many different tokens.

Smart contracts allow developers and users to extend the functionality of tokens by deploying new smart contracts to a blockchain. It is possible to move tokens between blockchains by creating locking or bridging mechanisms in dedicated smart contracts.

What is a Smart Security Token?

A Smart Security Token (SST) is a US registered security that can also be used as a token in blockchain distributed applications (Dapps).

Prometheum’s Blockchain and SST design support the use of tokens in regulated and utility applications. This is done by providing mechanisms for the movement of SSTs between “Master” and “Personal” wallets. Master Wallets (MWALs) are a means of SST accounting used by Clearing Firms alongside the Management Wallets (GWALS) that they use to work with the Prometheum Blockchain. Personal Wallets (PWALs) are much like wallets on other public blockchains. Investors and Dapp users can create PWALs to interact with Smart Contracts on the part of the Prometheum Blockchain that is open to the public (the Prometheum Utility Blockchain).

Prometheum’s SST design is based around the existing concept of “certificated” securities. The processes used by Prometheum’s SST design are based on regulatory-compatible processes used for existing certificated securities. These processes can be modified and adapted to meet the requirements of different jurisdictions.

SSTs are created by Prometheum’s Issuance Platform as a set of Smart Contracts that adhere to templates created by Prometheum.

Ember is Prometheum’s own SST. It behaves the same way as any other SST created on the Prometheum Blockchain, but it has the additional property of being the underlying means of payment for transactions on the Prometheum Blockchain. See Payment by Ember and Fixed and Variable Fees for more information.

Varying Regulatory Requirements

In addition to the Prometheum Blockchain, Prometheum is building a suite of trading applications and services to support its business model. Each of these applications and services interact with the Prometheum Blockchain in different and specific ways that complement their business model and processes. More information about the purpose of each of these functions is in ‘Appendix 1 – Key Stakeholders’, but the specific functionality of external systems is not covered by this document.

Each jurisdiction has different requirements for regulated entities, investors, traders and users regarding blockchain securities. Prometheum’s multi-chain design allows for these requirements to be met with jurisdiction-specific Core chains. Most of the examples in this document refer to a US Core Chain and US regulated entities. See ‘Multi-Chain Design’ for information about integration of different chains.

Each each jurisdiction has common underlying principles:

•

Distribution – how are SSTs created and why; how are they delivered to their owners

The use of multiple chains relies on different wallet types that represent custody in different ways depending on whether an SST is in a brokerage account ready to trade on the ATS or held directly by its owner to use in a utility application. This is discussed further in ‘Wallet Structure’, but can be summarised as follows:

Management Wallets – are used by a Clearing Firm to custody SSTs in brokerage accounts. They exist on a Core chain.

Master Wallets – are used by a Clearing Firm to represent individual account holder custody and SST balances. They exist on a Core chain.

Personal Wallets – are used to hold (and represent a public balance) of SSTs held directly by their owner. SSTs held in PWALs can’t be actively traded on the Prometheum ATS when in a personal wallet, but the wallet holder can transfer and use their SSTs as they wish on the public Utility chain.

In Brief… Custody

SSTs exist as entries in a set of Smart Contracts on the Prometheum Blockchain. A full record of all SSTs is obtainable directly from the Prometheum Blockchain.

Movement of SSTs in Master Wallets is done as part of the Clearing Firm’s settlement process.

Movement of SSTs in Personal Wallets is managed directly by SST owners on the Utility chain.

The Issuance Platform’s Transfer Agent Services maintain a full record of SST ownership by combining public blockchain data with private account holder data from Broker-Dealers.

Multi Chain Design

Prometheum Blockchain’s SST design is reliant on a split Core/Utility chain model, where all regulated activities occur on a Core chain and Dapp activities happen on the Utility chain.

This design has the added technical benefit that the scaling requirement for each chain can be treated differently. On a Prometheum Blockchain Core chain, there is a predictably high throughput of very similar transactions primarily from applications and services controlled by Prometheum. On the Prometheum Utility Blockchain, there is an unpredictable (but initially - i.e. at launch - low) number of potentially varied transactions.

The Utility Chain

The Prometheum Utility chain is intended as a location for SSTs that aren’t currently held in brokerage accounts. Wallets on the Prometheum Utility chain are held and managed directly by SST owners. Any wallet holder can deploy smart contracts to the Utility chain.

The Prometheum Utility chain can also be used to bridge between multiple Core chains or to other public or private blockchains.

The Core Chain(s)

For each supported jurisdiction, Prometheum creates a specific Core chain. Each of these Prometheum Core chains is built around the requirements for securities in that jurisdiction. Typically, the issuance and transfer of SSTs on a Core chain is done only by regulated entities.

US Core Chain example

Prometheum’s initial US Core Chain and Utility chain have the following features:

GWAL and MWAL transactions (method calls) occur on the Core chain. All PWAL transactions occur on the Utility chain. As PWAL-held SSTs are the equivalent of certificated securities, users can move them freely to other users (e.g. for payment, as a gift) so long as a record of PWAL-SST ownership is maintained.

Only GWAL holders can sign method calls on the Core chain, this includes primary regulated SST interactions (e.g. ExecuteTrade, Settle, TransferToPWAL, TransferFromPWAL, Create/ApprovePWAL) .

The balances of an SST on the Core chain and the Utility chain are separate. Only the transfer functions involving PWALs interact with both (via a pegging mechanism).

For each SST on the Core chain, a ledger of PWAL-owned SST (with category/class information) is maintained on the Utility chain. Category and class information is SST specific, e.g. an SST might have different classes (like classes of securities), the balances of which need to be maintained between Core and Utility chains.

All transfers of SSTs on the Utility chain are completed via the SST/PWAL contract (e.g. via calls from other general purpose contracts)

Because general purpose smart contracts can be published on the Utility chain(s), users can implement their own SST pegging with other chains. This could be other Prometheum Utility chains, or non-Prometheum blockchains with compatible smart contracts.

In Brief… US Core Chain

The Prometheum US Core Chain is the first SST Core chain and allows for the issuance, custody and trading of SSTs in the United States. Our US Core chain is paired with a Reg A+ offering process that allows accredited and unaccredited investors to purchase and trade SSTs.

What are ‘General Purpose’ smart contracts?

Smart contracts can typically be created and deployed by anyone with access to the applicable blockchain and a sufficient amount of that blockchain’s payment unit.

Prometheum’s blockchain has a number of built in SST smart contacts to support transfer of SSTs and movements of SSTs between chains. These are the “SST Smart Contracts”. All other smart contracts are referred to as “general purpose”.

On the Prometheum blockchain, fees are paid in the Ember SST, so any holder of Ember can deploy a general purpose smart contract.

All transactions (contract deployment, method calls) on the Utility chain(s) are paid for with the Ember SST, held in PWALs on that Utility chain.

Requirements for running validating nodes on the Core chain are more strictly assessed than on the Utility chain. It is expected that validators will provide services and prove throughput on the Utility chain or a test chain before being able to bid on validating the Core chain. Core chain validators will need to meet certain compliance factors to receive approval.

Multi-jurisdiction, Multi-core support

Prometheum’s Blockchain is designed to provide a vertically integrated solution for blockchain securities compatible with various jurisdiction and technology requirements by addressing two separate sets of concerns:

Function as a security (investment), with all that entails, e.g.

Offering to the widest possible set of investors under an appropriate regulation (i.e. as a method of capital formation)

Secondary trading via an appropriate trading venue (e.g an ATS in the US)

Satisfying regulatory requirements on a per-issue and per-jurisdiction basis (e.g. including issuance, custody, trading information, due diligence, infrastructure and individual investor/token-holder requirements)

Function as a token, e.g.:

Direct management of a token (SST) in a wallet managed by the user

Use of the token as a form of payment in a smart contract format

Use of the token for other smart contract features (e.g. locking a token in a smart contract)

Ability to buy (or sell) the token (SST) in a reasonable manner via a trusted party

(Image)

Prometheum’s Blockchain supports both sets of requirements by providing key components:

•

Jurisdiction-specific Core chains

•

A shared public Utility chain

•

A smart contract layer that coordinates SST use across the Prometheum Blockchain

•

Utilities and tools to support specific regulated entities and/or integrations

Although the token requirements are generally shared or overlap between most users (particularly as a smart contract layer allows users to support many different token functions), different jurisdictions or offering scenarios present different requirements for the security / investment contract part of the SST’s functionality. To address this, each Prometheum Core chain can support different mechanisms for different requirements, e.g.:

(Image)

Prometheum and Public Chain Transfers

Transfers of SSTs can happen between Prometheum and other blockchains, including at least:

•

US Core <> Utility – regulated process whereby the Clearing Firm and Broker-Dealer manage the transfer of a user’s SSTs between the Prometheum US Core and Utility chains.

•

Other Core <> Utility – regulated process supporting a different jurisdiction. It is expected that all jurisdictions will have some form of jurisdictionally-qualified regulated entity involved in these transfers.

•

Core < Utility > Core – it’s possible to move SSTs between different Core chains by moving them to the Prometheum Utility chain. Both Core chains will have applicable due diligence and provenance requirements for these transfers.

•

Utility <> Public Chain – by deploying a bridge or locking contract to the Prometheum Utility chain, issuers can support SST interactions between Personal Wallets on the Prometheum Utility chain and other public or private blockchains

•

Utility <> Public Protocol – Prometheum or SST issuers may implement support for the general inter-blockchain transfer or bridging protocols (e.g. the IBC / Inter-Blockchain Protocol)

•

Utility <> Utility – SSTs held in a Personal Wallet can be used as a form of payment on the Prometheum Utility Chain. These transfers can be initiated directly by users or other smart contracts.

Because of the nature of SSTs (i.e. they are smart contracts deployed to one or more Prometheum chain) it’s possible to support the creation and issuance of SSTs that have changing regulatory status over time. For example, an SST that falls under the Reg S exemption in the United States may later (after meeting all applicable requirements and due diligence) be considered to have all the same features as one issued directly in the US under Reg A+.

Shared Contract Layer

Each Prometheum Blockchain will have a smart contract layer that supports the template SST smart contracts as well as general purpose smart contracts.

It’s likely that most (including the US) Core chains will have very limited use of general purpose smart contracts as only regulated participants can send transactions to those chains.

More information is provided in the ’SST Smart Contracts’ section.

Multi-Stage Approvals

Functions of SSTs provided by the Prometheum Blockchain allow for “multi sig” like processes. I.e. a system whereby multiple users/network participants can authorise (or deny) a particular action or process. This is an essential part of building a reliable, regulatorily-compliant business system.

What is a ‘Public Chain’?

A public chain is a blockchain that is generally accessible to any interested party (e.g Ethereum, Bitcoin). Interacting with a public chain typically involves acquiring some of that chain’s payment unit or token (e.g. Ether in the case of Ethereum).

In Brief… Multi Stage Approvals

Multi-stage approval is a concept that allows for multiple parties to be involved in approving or “signing” a specific action. Normally this is initiated by one party and then under some pre-defined parameters multiple other parties approve the action.

Prometheum Blockchain makes extensive use of multi-stage approval in order to ensure integrity and resilience in smart contract processes involving regulated entities.

What is a signature?

A signature is a piece of computer-readable text that confirms that a party with some secret information (a private key) has acknowledged or “signed” a particular message.

Signatures are often used to get permission from one party for another party to take an action on their behalf, without the receiving party having the ability to take other unapproved actions.

The multi-stage approval features are built at the Smart Contract layer by using a staged implementation (whereby a Smart Contract waits for several stages of message signatures). These methods are compatible with offline signing.

Typically, signatures used in multi-stage approvals will:

Always include some nonce or sequence identifier (e.g. to avoid signature reuse)

Include sufficient identifying process/operation and identifier information (e.g. a signature for transferToPWAL at least indicates both the type and a unique identifier for this transfer to a PWAL)

Include the plaintext data (it’s assumed that signatures are not of sensitive data)

Include the address of the signer

Will be considered valid if it’s a valid signature for the provided plaintext from an address expected by the receiving method/contract/process

Cold Storage

The multi-stage-approval-by-contract mechanism is compatible with offline signing. A participant in a multi-stage approval can chose to produce a signature using a computer or device not connected to the Prometheum Blockchain or the internet.

In cold storage scenarios, the cold storage facility is typically set up in advance and shares its public keys with the operational “hot” wallet and ultimately the relevant smart contracts.

(Image)

What is a ‘nonce’?

When using signatures for approval there can be circumstances where the message that requires a signature is identical to a previous or future message. In order to prevent a receiving party reusing a signature, a “nonce” is inserted into the message to ensure that it is unique and cannot be reused.

What is a Cold Storage?

Cold storage refers to the ability to have parts of an electronic system operate in a manner that is completely disconnected (“cold”) from any computer networks, including the internet.

By using a cold storage mechanism the risk of external attack or system compromise is significantly reduced.

Example “cold” storage signature process:

Location	action
online computer	get plain text data requiring signature
offline “cold” computer	copy plain text data using intermediary device (a USB device or other reliable portable storage mechanism
offline “cold” computer	produce signature by signing plain text with appropriate private key*
offline “cold” computer	copy signed plain text (the signature) back to intermediary device
online computer	retrieve signature from intermediary device
online computer	call a Smart Contract’s approval/multi-stage process using the signature provided by the offline device

* The actual mechanism used to store the private keys used to create this signature is up to the participant. A participant may choose to use additional techniques to further secure the multi-stage approval process.

By implementing the transfer of SSTs in smart contracts with built-in multi-stage approval processes it is possible to limit the storage of SSTs to only “cold” storage (i.e. any movement of that SST requires an offline/cold signature).

Public Verifiability

Users of distributed systems and tokens expect to be able to verify key features of tokens and their current location. It is typical in a blockchain to be able to see the total number of tokens issued, the total number in a wallet at any given time and often also the specific points in time that a token was transferred between wallets.

Most jurisdictions however limit the amount of public information that can or should be revealed about the location of securities (e.g. current ownership of securities in brokerage accounts held in custody at a clearing firm).

Prometheum’s Blockchain meets both of these needs through its settlement distribution and derived address systems (see ’Settlement Distribution’).

On the Prometheum Utility chain all SSTs locations and transfers can be seen. On Prometheum Core chains the total number of SSTs, the amount held in custody by a Clearing Firm and the total amounts of settlements (transfers as a result of secondary trading) can be verified. However, because of the derived address system used for Master Wallets it’s not possible to publicly assert the current total holdings or activities of any individual brokerage account holder.

In Brief… Public Verifiability

Prometheum Blockchain allows for the public verification of all SSTs issued, held and transferred on both the utility and Core chains. However it’s not possible to infer the current total holdings of any specific account holder activity on a Core chain.

Prometheum’s stance on public verifiability meets the expectations of public distributed systems whilst also meeting the needs of regulated entities.

Composable SSTs

Prometheum has intentionally set about creating SST systems and principles that can be reused by many issuers and providers. The Ember SST is the first SST and uses the base SST template contracts. As more issuers use our platform to issue their own blockchain securities, the library of composable SST components will increase.

More information about the creation of SSTs via smart contract can be found in the ’SST Smart Contracts’ section.

Payment by Ember

Transaction fees on both the Prometheum Blockchain Core and Prometheum Utility Blockchain will be paid using the Ember SST. The Ember SST is the first Prometheum SST and uses the base templates available to all other SSTs.

Prometheum system contracts and functions manage the translation of Ember SST balances for the purpose of paying effective gas fees. More information can be found in the ‘Transaction Liquidity Provider’ section.

Systems

Underlying Blockchain

The underlying blockchain technology used to build the Prometheum Blockchain provides:

•

A distributed ledger (no single points of failure or centralized services at the underlying technology level*)

•

Appropriate consensus mechanisms for Core and Utility chains

•

Smart Contract compatibility and a standardised language across Core and Utility chains

•

A public blockchain with permissioned account access for the Core chains

•

Public verifiability (it will be possible to read data from Smart Contracts and events without having any pre-requisite permissions)

•

A scalable design for ongoing governance and future chains

•

Compatibility with read-only nodes

In Brief… Ember SST

Ember is the first SST issued on the Prometheum Blockchain. Ember is special in that it is used as the payment mechanism on all Prometheum Blockchains, but still based on the same SST contract templates available to other issuers.

Ember SST’s Reg A+ offering also sets out the regulatory mechanisms for the Prometheum infrastructure and systems.

What does ‘permissioned account access’ mean?

Generally, “permissioned” refers to the concept of requiring some authorization to create or act on a certain part of a system, e.g. to call or create a smart contract.

Permissioned account access on Prometheum Core chains means that only specific (normally regulated) entities can access certain features.

Even though there is a permissioned model for writing data on the Prometheum Core chains, they are still public in that any party can run a node and inspect data on the chain.

* Parts of Prometheum’s design (e.g. the creation of GWALs) assume that certain services are centralized in order to meet regulatory requirements. These will be implemented at the application/smart contract level to maximise the distributed nature of the underlying technology.

The Prometheum Blockchain also provides common application building blocks in the form of:

•

A reference node implementation

•

A node API

•

A wallet SDK

•

Blockchain explorer

•

Test and main networks

Wallet Structure

Prometheum Blockchain uses three wallets types:

Management Wallets (GWALs) – custody of SSTs at a clearing firm

Master Wallets (MWALs) – to represented custodied ownership of SSTs by specific account holders

Personal Wallets (PWALs) – to hold SSTs directly on the Prometheum Utility chain

Wallets can be used to hold SSTs, to call Smart Contract methods and to create signatures for use in multi-stage approval processes.

Access varies based on use, for example

Action	Core Chain	Utility Chain
Create a Smart Contract	GWALs	PWALs; GWALs
Call a Smart Contract	GWALs	PWALs; GWALs
Read data from a Smart Contract	Public	Public
Listen for events from a Smart Contract	Public	Public

What is a ‘read-only’ node?

A read-only node can observe and independently verify transactions on the blockchain but doesn’t contribute to consensus. Read only nodes are useful for providing quick access to data.

In Brief… Wallet Structure

Prometheum Blockchain uses multiple wallet types to allow for different requirements on the Core and Utility chains. Each wallet type works differently.

A PWAL is used on the Utility chain to interact with Dapps, send SSTs to other users and to send those SSTs to an MWAL via their Broker-Dealer so they can be traded on the Prometheum ATS.

Some of the non-regulated parts of the Prometheum system also use PWALs including the Auction system, for the purpose of bidding on staking/validating and receiving network incentive payments.

In order to get SSTs to their PWAL a user must receive them via a transfer from another PWAL or request a transfer from their MWAL via their Broker-Dealer.

Transferring SSTs from a MWAL on a Prometheum Blockchain Core chain or sending them to an MWAL (via their Broker-Dealer and the Clearing Firm’s GWAL) on a Prometheum Blockchain Core chain require a due diligence and AML/KYC process at the Broker-Dealer and Clearing Firm. This is implemented as a multi-stage approval processes in the applicable Smart Contracts.

Master Wallets (MWALs)

Master Wallets (MWALs) are a mechanism by which a Clearing Firm provides a verifiable public record of settlement between accounts that can a.) be associated to specific accounts and b.) be publicly verifiable against total SST distribution and executed trade information without revealing specific account holder’s transactions or total SST balance.

The term “Master Wallet” is also used generally to describe the concept of per-investor SST storage in a Prometheum Core chain. The actual storage of SSTs on a Prometheum Blockchain Core chain is done via a Clearing Firm’s GWAL settlement distribution system.

MWALs themselves don’t hold SSTs. MWALs do not interact directly with the Prometheum Blockchain Core or Prometheum Utility Blockchain. MWAL identities (the “root” addresses) are known only to the Clearing Firm.

MWAL Derived Address

Although the permissions associated with a Core Prometheum Blockchain and the Prometheum Utility chain restrict its use (a permissioned model), all information published to Prometheum Blockchain is considered public. In order to maintain publicly verifiable information while ensuring regulatory compliance, it is critical to not reveal:

•

the SST balance of an investor’s brokerage account (i.e. SSTs held at the Clearing Firm)

•

the detail of customer trades executed by the ATS

What Does ‘Transferring’ Mean?

Transferring is simply the process of moving an SST from one wallet to another wallet.

On the Prometheum Utility chain transfers work just like they do on other smart-contract enabled blockchains.

In Brief… Master Wallets

Master Wallets are used by the Clearing Firm to represent the current account holding of an SST owner. The balances in Master Wallets are a product of the settlements processes at the Clearing Firm. They relate to an investor’s SST holdings but don’t provide a direct public representation.

What are ‘root’ addresses?

All Master Wallets have a “root” address that is used to create (derive) all parts of the Master Wallet hierarchy. These root addresses are private and are only known to the Clearing Firm.

In order to allow for both the public verification of SSTs on a Prometheum Blockchain Core chain and the trading activity published by the ATS, the root MWAL identity is used exclusively by the Clearing Firm to provide a mechanism by which “derived” addresses can be created (and internally linked) for the purpose of calling settlement methods on the SST contracts.

See ’Settlement Distribution Algorithm’ for more information.

By using derived addresses, total settlements can be verified and the Clearing Firm can privately verify account balances. The total amount of SSTs in Prometheum Core and Utility chains is publicly verifiable while ensuring regulatory compliance with relevant rules and regulations regarding privacy of customer data.

Management Wallets (GWALs)

Management Wallets (GWALs) are required to:

•

Call methods on a Prometheum Blockchain Core chain

•

Custody SSTs on the Core chain (SST balances are represented by Master Wallets)

GWALs are used by regulated network participants to perform functions on a Prometheum Blockchain Core chain. A single entity (e.g. a Clearing Firm) will use several different GWALs for different purposes. The use of different GWALs is at the discretion of the stakeholder. An example is given below.

Specific SST Smart Contact methods that use multi-stage approval processes will specify GWALs as a valid signer for a particular stage of multi-stage approval process. The registration of these roles must be done by each GWAL that a multi-stage approval process relates to. For example, a GWAL that holds SSTs must register approval addresses for the various stages of its transfer methods (assuming that all transfer methods are subject to multi-stage approval).

Example GWAL types for a Clearing Firm:

•

Holding - Used to hold SSTs after an issue and before distribution to subscribers/investors

•

SST Storage - Used to custody SSTs for normal operations, e.g. all SSTs allocated to MWALs custodied in storage GWALs

•

Operations - A wallet used to call Smart Contracts and create online signatures

•

Offline - A wallet used to sign messages offline (i.e. cold storage)

In this situation a Clearing Firm would have a separate SST storage GWAL for each Broker-Dealer they service. The Clearing Firm could still use the same operations and offline signature GWALs for all Broker-Dealers.

In Brief… Management Wallets

Management Wallets are used on Prometheum Core chains for holding SSTs (i.e. the custody of SSTs is in Management Wallets represented by Master Wallet ownership records).

Management Wallets are also used for operational processes at regulated entities. For example, approving a transfer to cold storage will require the use of several different Management Wallets, all held and managed by different parties.

What is an ‘offline’ wallet?

Wallets are ultimately based on the ability to sign messages and manage private and public keys. Interactions with a wallet are normally broadcast directly to a blockchain via a computer network (normally the internet).

Offline wallets allow for users to sign messages and create keys without being connected to a network. They are an important part of a cold storage and multi-stage approval system.

Auction System

The Prometheum Activity Auction (PAA) system allows for network participants to place bids in activity auctions to become eligible as service providers for a number of network and business functions. This includes validation of blocks on Prometheum Core and Utility chains.

The smart-contract-based PAA will be complimented by a web-based interface that will be part of the Prometheum “Platform” tools (including issuance, issuer services etc).

The implementation of the PAA will include:

A PAA-Providers smart contract that can be used by providers to register their PWAL addresses, where required (e.g. for a Core network validation position) seek approval from the Prometheum network and (once approved) obtain a Provider reference.

A PAA-Auctions smart contract that will manage running auctions and auction types. It will also interface with other specific auction contracts to receive information about participant eligibility. An activity might, for example, stipulate specific criteria for how often a provider can bid for a service.

A PAA-Payouts smart contract manages payment to providers of Activities, including integral fees (e.g. Validators receive transaction fees) and incentives (if applicable and active for the service being provided).

In addition, the Core contracts include:

A PAA-Activity-Validator smart contract that will integrate with the Core auctions contract as well as publish a list of applicable Validator addresses for each period. The PAA-Activity-Validator contract can also be called by internal system methods to receive information about validator behaviour in a consensus period.

Participant Selection

It is expected that activity participants are selected based on a verifiable random selection (VRF / Verifiable Random Function) of eligible bidders.

Auctions in the PAA system will have different characteristics. The following auction types may be possible:

Min cost / lowest fee (Providers bid to provide the most cost-effective service)

In Brief… Auction System

The Prometheum Auction system allows for network participants to place bids in activity auctions to become eligible as service providers for a number of network and business functions. This includes validation of blocks on Prometheum Core and Utility chains.

What is ‘VRF’?

A verifiable random function (VRF) allows for a set of distributed entities to agree on a “random” number or sequence that can’t be unduly influenced or manipulated by any specific party.

The VRF in the Prometheum auction system improves the economic stability of validation by allowing for larger number of validators to compete for validation spots than are technically required to operate the consensus algorithm.

Highest stake (Providers compete by staking more Ember)

Reputation Hybrid (newer providers have to stake/bid at a penalty)

Additional information may also factor into bid eligibility for Providers, including:

Previous service provision (e.g. Activities may publish data about performance or track record of providers)

Previous service provision in another activity (e.g. Validators on a Prometheum Blockchain Core chain may have to first Validate the Prometheum Utility Blockchain)

Additional due diligence (some activities may require a greater level of commercial due diligence)

Incompatible services (there may be mutually exclusive combinations of compatible services, for technical or commercial reasons)

Previous provision (e.g. some services may favour new Providers)

Activities may also have different characteristics for their auctions, e.g.:

Some Activity auctions may implement staking penalties

Some Activity auctions may charge a fee to bid

Activity Initiation

In order to provide a service, bidders may be required to provide additional information for the specific activity auction. This may be done:

Before bidding to establish eligibility

At the point of bidding

Upon being selected as a winning bidder

The provision of that information will typically be done by either:

Sending the information to the Auction smart contract

Sending the information to some other (off chain) system with a signature using the PWAL associated with the auction bid

Auction System for Validators

The Auction System is a means by which validators/stakers on the Prometheum Blockchain Core or Prometheum Utility Blockchain can place bids or take off-chain actions to participate in staking. In addition to off-chain interfaces and data, the Auction System will be presented as a set of Smart Contracts on the Prometheum Utility Blockchain (for both Core and Utility chain staking) that can be used by stakers (stakers place their bids via a Prometheum Utility Blockchain smart contract using Ember in PWALs).

In order to inform the Prometheum Blockchain of valid stakers the Auction System will call smart contracts on both the Prometheum Blockchain Core and Prometheum Utility Blockchain. It will use the same methods (Smart Contract calls) to find out information about stakers’ performance in previous rounds.

Auctions for validators are expected to:

Require test network or Utility-chain validation before reaching applicability on the Core chain

Meet specific off-chain requirements for validating Core chains during their launch periods

Provide an overlap of staking and auction periods (e.g. it is not possible to use the same stake for consecutive validating periods)

Use validator data in future validation selection (e.g. requirements for staking may incorporate data from previous behaviour by this validator)

Stakers/validators participating in staking will receive payments in Ember based on the (fixed or variable) transaction fees paid by users of the Prometheum Blockchain.

The Auction System may also reward stakers/validators with network incentives (further payments in Ember) based on information provided by the consensus mechanism.

(Image)

Contextual example of the auction system’s interactions with the system functionality on the Prometheum Blockchain.

The Auction System will interact directly with the Prometheum Blockchain by:

•

Running nodes on both Core and Utility chains

•

Updating a Smart Contract (on both Core and Utility chains) with information about valid stakers for the current/next round

•

Inspecting/calling Smart Contracts (on both Core and Utility chains) to read information about staker performance in previous rounds

Issuance Process and Transfer Agent Systems

Prometheum’s Issuance Platform provides a number of things:

A point of coordination for all parties involved in issuing an SST

A platform by which issuers can promote their offerings and investors can sign up to invest in them

A place to hold SST records from broker-dealers and issuers for the purpose of meeting transfer agent requirements.

Prometheum’s SST Smart Contracts provide the basis of gathering required information for transfer agent purposes. By combining the account holder information shared privately by the clearing firm with the individual information available to a broker-dealer and the transfer and custody records available from the blockchain, the Prometheum Issuance Platform provides a means by which issuers can meet their transfer agent requirements without unnecessarily revealing any data.

Fixed and Variable Fees

The Prometheum Blockchain Core and Prometheum Utility Blockchain will use different fee models.

Prometheum Blockchain Core chains will use a fixed fee model, whereby every Smart Contract method call has a fee in Ember associated with calling it. The fixed fees for calling a method will be determined periodically by Prometheum and updated using a system Smart Contract.

The Prometheum Utility Blockchain will use a variable fee model based on a difficulty calculation. The rate of fees (an “Ember gas rate”) will be determined periodically by Prometheum and updated using a system Smart Contract.

Transaction Liquidity Provider Service

Broker Dealers interacting with the Prometheum ecosystem may choose to provide a Transaction Liquidity Service whereby on-chain (Ember) fees are paid using another SST or arrangement with a specific user.

In Brief… Issuance Process

The issuance process is the means by which an SST comes into being. It involves the issuer and a number of regulated service providers coming together to make the offering and create the SST.

The Prometheum Issuance Platform automates this process for issuers and also provides the basis for the required Transfer Agent Services.

What are ‘Variable Fees’?

Variable fees (or complexity fees) are commonly used on public blockchains as a means to charge users of smart contracts a fee (to validate or process) based on the complexity and amount of computational work involved.

In Brief… Transaction Liquidity Provider Service

Prometheum’s Transaction Liquidity Provider service allows issuers to make arrangements for users of their smart contracts to pay the transaction fees (for calling the smart contracts) using something other than the Ember SST.

This allows issuers to encourage the use of their own token as a means of exchange and payment on both the Prometheum Utility Blockchain and anywhere else it might be used.

Such a system would allow Transaction Liquidity Providers (TLPs) to issue payment vouchers that the network can redeem against staked/reserved Ember.

The TLP service in this example can be summarised as:

•

Transaction fees on the Prometheum Utility chain are paid in Ember

•

The User holds an SST that is not Ember (SSTX)

•

The User wants to pay transaction fees in SSTX

•

The User is willing to pay a small fee in order to pay fees in SSTX

•

The TLP (a registered Broker-Dealer) is willing to exchange SSTX for Ember at market rate plus a commission

•

The TLP meets other criteria required to provide the TLP service (e.g. has staked Ember in an activity auction and holds a sufficient balance of Ember)

In order to facilitate this style of TLP:

•

The User and TLP will have a means of coming to an agreement for TLP provision

•

It is possible for that TLP provision to be put in place without the User ever holding Ember

•

The TLP provision will secure an amount of SSTX (e.g. so the TLP can guarantee receipt) and an amount of Ember (so the System can debit transaction fees)

•

The User or the TLP can cancel the TLP agreement and associated provision within defined terms

•

The system can check for a valid TLP provision (where it would normally check for a balance of Ember)

•

The system will move SSTX from the User’s PWAL to the TLP’s PWAL and pay the fee using the TLP’s PWAL (where the system would normally debit the User’s Ember balance to pay a transaction fee)

•

The system will be able to transfer SSTX on behalf of the User and Ember on behalf of the TLP

The total provision amount available (i.e. maximum liquidity available)

In order to use a service without calling a smart contract (which would require Ember), the User provides a message signature to the TLP off-chain. The TLP passes this signature to the TLP smart contract to start the service.

User signs and provides signature (as well as plain text parameters) to TLP (this is off chain, and can be facilitated by the Prometheum issuer platform tools)

TLP calls the start method of the TLP smart contract with the signature and parameters and the current market rate

TLP contract sets up the provision:

confirms balances of SSTX (User) and MBR (TLP)

confirm that the user doesn’t already have a TLP provision in place for this PWAL

locks SSTX by amount specified in User’s PWAL

locks MBR by amount specified multiplied by rate in TLP PWAL

adds TLP provision to global register

During normal transaction processing the System will use a TLP to pay fees if available. Note this assumes that the User has Ember in their PWAL that will be used to pay transaction fees.

Upon processing a transaction where the User does not have Ember in their PWAL, the system will:

Look for a valid TLP for this PWAL (transaction is rejected if none found)

Check available balance (in Ember) of the TLP Provision (transaction is rejected if not sufficient) against the gas limit provided by the caller (User)

Process the transaction and calculates the gas used

Spend Ember from the TLP’s locked Ember balance associated with this TLP provision

Transfer SSTX from the User’s locked SSTX balance associated with this TLP provision to the TLP’s PWAL at the rate indicated on the TLP contract (set and updated by TLP, see below)

Update balance of agreement

If the remaining balance is less than the minimum reasonable transaction fee (set by system) the TLP provision is cancelled by the system

The TLP will need to periodically update the market rate for their service. This can happen as a single smart contract call for all current provisions.

When the rate is updated the amount of locked Ember is also updated. If the new locked amount can’t be met (by the TLP’s associated PWAL) then all active TLP provisions will be cancelled.

Either the User or the TLP can cancel the service:

Call “cancel” method on TLP contract with provision reference

Provision is removed from register

Remaining locked SSTX is unlocked (User)

Remaining locked MBR is unlocked (TLP)

It is assumed that the TLP will update to cover the fluctuating market rates of both SSTX and Ember. The rate they report to the TLP contract would include any commission.

The TLP can maintain a PWAL specifically for the purpose of operating a TLP.

Settlement Distribution

The Settlement Distribution Algorithm will be used by a Clearing Firm to determine how to distribute settlements between derived MWAL addresses. This is done in a manner that is efficient and does not reveal confidential information when writing settlements to the blockchain.

It is assumed that this algorithm:

•

Does not provides information about the total amount of any settlement

•

Does not re-use addresses

•

Considers the optimal number of required addresses for any settlement action or set of settlement activity in a trading session

•

Considers the amounts used to accurately aggregate settlements without leaking information

The algorithm ensures that it is not possible to assert that “there is a single investor who has traded X amount of SST Y in a single session”, or that that “there exists a single investor with X amount of SST Y in a single account.”

It is possible to inspect the public data (local contract storage or data emitted by events) on a Prometheum Blockchain Core chain to assert the total amount of SSTs in a GWAL or the total amount of SSTs settled by a GWAL in a single session without knowing any information about that session other than the session identifier.

Use of the algorithm:

•

Provides public verifiability of settlement information by reading public information from the Prometheum Blockchain

•

Provides the ability to link settlements to executed trade information using only a trading session identifier

•

Ensures that settlements cannot be grouped to gather information about any potential individual investor

Derived Address Creation

As the Settlement Distribution Algorithm relies on using opaque settlement addresses, a mechanism is required for a Clearing Firm to generate these addresses in a reliable fashion.

By using the Settlement Distribution Algorithm, a Clearing Firm must be able to prove that their process for derived address creation can:

•

Generate unique addresses

•

Produce addresses that cannot be linked to each other using public information

•

Keep a reliable record of which account addresses belong

SST Smart Contracts

Every SST is created as a set of “Core” (on a Prometheum Blockchain Core chain) and “PWAL” (on the Prometheum Utility Blockchain) contracts. These SST contracts are based on templates produced by Prometheum and deployed to the Prometheum Blockchain by the Issuance Platform, thus ensuring all SSTs adhere to a single standard.

For the purposes of system compatibility, all contracts implement the same fundamental properties for SSTs, including:

	Standard	Example for Ember
SST Name (tradable unit)	Unique, name of the SST whole unit	Ember
SST Symbol	Unique, identifiable “ticker” symbol	MBR.ST
Base Unit	Unique name for non-divisible underlying unit	Spark
Decimal Precision	Same for all SSTs (e.g. 10^18)	As per standard
Total Supply	Integer amount of tradable unit (total issued specific to each SST)	270,000,000

All SSTs have a list of known “classes”. The balance of each class will be be managed separately in both Core and Utility chains. Stakeholders may implement restrictions (e.g. a particular SST cannot trade on a secondary market) for certain classes. These restrictions are implemented in the systems of the Clearing Firm, Broker-Dealer or ATS.

What is a Derived Address?

Derived addresses (or HD Wallets as they were originally referred to in Bitcoin) allow for a series of addresses to be generated from one root/master address. This means that transactions can be seen publicly but not linked together unless you have access to the private information associated with the root address.

In Brief… SST Smart Contracts

SST smart contracts create SSTs themselves and also set out the means by which all related processes can occur. This includes custody and transfer on both Core and Utility chains.

What is a smart contract register?

A smart contract register is a special type of smart contact (or related system) that allows creators of smart contracts to publish information about the smart contracts they have created.

It also allows for smart contract creators to update their contacts and provide a reference to the most recent version.

All smart contracts will publish events to be used by integrators.

SST Contract Register

A register of SST contracts on both the Prometheum Blockchain Core and Prometheum Utility Blockchain will be maintained by the Issuance Platform. This register will record identifying SST information (including a unique identifier for each SST, e.g. “MBR”) as well as a location for the SST’s smart contracts.

SST Templates

SSTs are made up of contracts derived from Prometheum-provided SST templates. Ember uses the SST Core Features template. Each SST may use different features depending on its specific requirements.

(Image)

SST Templates provide the building blocks for a variety of different blockchain securities created with Smart Security Tokens

SST Function Permissions

The Smart Contract accounts system will provide a mechanism to restrict calling methods on smart contracts on a Prometheum Blockchain Core chain.

The specific granting of permissions will depend on the structure of GWALs implemented by a Clearing Firm, ATS or Broker-Dealer, but using the example from the previous section, these would be implemented as follows:

Smart Contract Action	Permitted Callers
Register an address for a specific approval stage	CF1-SST-Storage
Distribute an SST	CF1-Holding
Settlement of trades	CF1-Operations
Execution of trade	ATS1-Operations
Transfer SST to another GWAL	CF1-Operations

Approve or reject transfer SST to another GWAL	CF1-Operations; CF1-Offline
Transfer SST to a PWAL	BD1-Operations
Approve or reject transfer SST to a PWAL	BD1-Operations; CF1-Operations; CF1-Offline
Receive SST from a PWAL	CF1-Operations
Approve or reject receive SST from a PWAL	CF1-Operations; BD1-Operations; CF1-Offline

SST Core Chain Functions

This section includes an example set of contract functions for the base building blocks of the SST smart contracts on the Prometheum US Core Chain.

Distribute an SST

Used by a Clearing Firm to distribute SSTs to their initial owners (works like settlement). Information about which accounts to distribute to is provided by a Broker-Dealer.

Execute Trades

In order to facilitate public verification of trading activity against settlement information, the ATS writes information about trades to a Prometheum Blockchain Core chain. It should only include otherwise publicly available information.

Information required to be written to a Prometheum Blockchain Core chain:

•

Session Identifier (used to reconcile against session identifiers in settlements, which happen at a different time)

•

The SST identifier (this is also identifiable from the smart contract being called, as each SST presents its own set of Smart Contract methods)

•

Class (used by issuers to differentiate different classes of a single SST)

•

Amount (the total amount, in the indivisible base unit of the SST)

•

Timestamp (of the trade)

•

Trade Type (used optionally by the ATS should it want to represent different types of trades, e.g. including adjustments)

The ATS may choose to record a unique identifier for the written information (e.g. a transaction hash/identifier) for the purpose of internal reconciliation. No uniquely identifiable information about the trade will be written to the Prometheum Blockchain. This could result in executed trades being written with identical apparent information (e.g. same SST, class, amount, timestamp).

Settle Trades

At the conclusion of every trading session the Clearing Firm will make a series of settlement calls that occur over the course of the following trading session.

The use of the settlement methods will consider any transfers requested during the same session (i.e. transfers to PWALs should be reflected by settlements in the same session).

The information written would include the derived addresses, the SST class, the amounts and the trading session identifier used to associate these settlements with executed trades written by the ATS.

The use of derived MWAL addresses for settlements is dictated by the Settlement Distribution Algorithm (provided as a supplemental tool of the Prometheum Blockchain).

Move SSTs between GWALs

Used by a Clearing Firm to transfer a balance of an SST (of a particular class) to another GWAL.

This could be used to transfer between different GWALs at the same Clearing Firm or to another Clearing Firm.

Transfers outside of the control of the Clearing Firm will be reflected by settlement calls to reduce the balance of the respective MWALs by the same total amount.

Requires a multi-stage approval process that includes an offline (cold storage) signature from the Clearing Firm.

Transfer SSTs to a PWAL

Used by a Clearing Firm to transfer a balance of an SST to a PWAL. This request comes from the PWAL owner via their Broker-Dealer.

PWAL owners require a sequential nonce in order to prevent requests signatures being reused (e.g. this is included as a “sequence” number in the request).

Would be called by a Broker-Dealer with the appropriate permissions upon request of an account holder.

Requires a multi-stage approval process that includes an offline (cold storage) signature from the Clearing Firm as well as due diligence provided off chain by the Broker-Dealer and Clearing Firm.

Upon completion of the multi-stage approval the balance of the Clearing Firm’s GWAL would be updated, the Clearing Firm would adjust the balance of the PWAL on the Prometheum Utility Blockchain and settle the MWAL on that Prometheum Blockchain Core chain.

Receive SSTs from a PWAL

Used when a PWAL holder wants to move their SST to their brokerage account (e.g. to trade them on the ATS). This process is subject to due diligence and AML/KYC checks at the Broker-Dealer and Clearing Firm.

Note that because of the public nature of PWAL transfers, the Broker-Dealer will use information available on the Prometheum Utility Blockchain as part of the due diligence process.

Is called by the Clearing Firm upon observing a call to transfer to an MWAL on the Prometheum Utility Blockchain. See note about naming in 4.3.2. Transfer to MWAL.

Requires a multi-stage approval process that includes an offline (cold storage) signature from the Clearing Firm as well as due diligence provided off chain by the Broker-Dealer and Clearing Firm.

Upon completion of the mutli-stage approval the balance of the Clearing Firm’s GWAL would be updated, the Clearing Firm would adjust the balance of the PWAL on the Prometheum Utility Blockchain and settle the MWAL on a Prometheum Blockchain Core chain.

SST Utility Chain (PWAL) Contract Functions

This section includes an example set of contract functions for the base building blocks of the SST smart contracts on the Prometheum Utility chain that are applicable to the interaction with the Prometheum US Core Chain.

Transfer

PWAL users can transfer SSTs to other PWALs using this method so long as the destination PWAL address has been granted the PWAL account type by the Clearing Firm.

The events emitted by this method are monitored by the Issuance Platform for the purpose of maintaining transfer agent service and record information.

Transfer to a Master Wallet

Used by a PWAL holder to initiate the transfer of an SST to their MWAL via their Broker-Dealer.

A “lock up” associated the PWAL’s SST will apply until a confirmation or completion from the Broker-Dealer/Clearing Firm using the “complete” and “cancel” methods occurs.

A note on naming: From the perspective of the user when a user moves SSTs from the Utility chain to the Core chain they are sending the SSTs to their “Master Wallet”. However, much as funds held at a brokerage account are actually held in a Clearing Firm/escrow bank account on behalf of the investor, funds in a master wallet are actually held in a Management Wallet on behalf of the user. In order to maintain consistency with naming the functional parts of the ecosystem, the transfer method on the Utility chain will be named “transferToMWAL” but specify a GWAL address as the recipient. The Clearing Firm is responsible for settling transactions to the user’s actual MWAL (via derived MWAL addresses).

Adjust Balance (Receive from a Master Wallet)

Used by a Clearing Firm to adjust the balance (positive credit) of a PWAL on the Prometheum Utility Blockchain as a result of a user requesting a transfer to a PWAL (note that transfers from PWAL to MWAL are handled by “complete” and “cancel” methods).

Appendix 1 – Key Stakeholders

Prometheum’s ecosystem is made up of a number of businesses, users and user types in the blockchain and regulated financial industries.

The Prometheum Blockchain is just one part of a wider set of applications and systems. The Prometheum Blockchain is not the only technology being developed by Prometheum and although it is used by most of the Prometheum ecosystem stakeholders, it is not the only means by which they interact, share data and do business - technically or otherwise.

This provides a general set of requirements for the Prometheum Blockchain, all of which come together to provide functionality for the following stakeholders and system users. It does not provide a specification for the related stakeholder systems listed below.

Prometheum Inc

Prometheum grants the GWAL account type for Prometheum Blockchain Core chain users (Clearing Firm, Broker-Dealer, ATS).

In the pre-launch period Prometheum Inc will provide the effective governance and policy decisions for fees, rates and staker requirements. Much of this functionality will be handed over to a monetary/chain policy subcommittee established by Prometheum Inc after the public launch of the Prometheum Blockchain.

Prometheum itself will interact directly with the Prometheum Blockchain by:

•

Creating system smart contracts

•

Granting account types for GWALs (to Clearing Firms, Broker-Dealers, ATS)

•

Setting transaction fee rates (for fixed and variable fees) by updating smart contracts

Clearing Firm

The Clearing Firm uses a traditional post-trade system to calculate updated account balances.

This information is passed to the settlement system, which connects to the Prometheum Blockchain via the application layer.

The Prometheum Blockchain provides a means to provide public verifiability and location of SSTs as well as transfer of SSTs to and from the regulated (securities) and unregulated (Dapps) spaces. It does not replicate a traditional clearing/settling function and any Clearing Firm using the Prometheum Blockchain will do so along with other tools for traditional clearing/settling methods and management of books and records.

The specific actions taken by the Clearing Firm in relation to the Prometheum Blockchain are defined in this document. Anything beyond that is something that is part of the Clearing Firm’s normal business operations and not part of the Prometheum Blockchain design or requirements. Accordingly, the requirements of the Prometheum Blockchain need to allow for a variety of Clearing Firm use cases and scenarios.

The functionality required by a Clearing Firm is to be provided by the Prometheum Blockchain node software and any additional relevant tools (see Additional Tools. It is up to the Clearing Firm to integrate this functionality into their own systems and processes.

A Clearing Firm will interact directly with the Prometheum Blockchain by:

•

Obtaining GWALs (by having addresses granted the appropriate type by Prometheum)

•

Registering approval addresses for internal multi-stage approvals (e.g. for the Clearing Firm’s own cold storage and operations addresses/processes)

•

Registering approval addresses for external multi-stage approvals (e.g. for a Broker-Dealer to initiate and approve the start of a transfer to PWAL process)

•

Using multi-stage approval processes for the activities in this list

•

Managing the creation of MWALs for investor accounts

•

Managing the tools to generate derived MWAL addresses (see Derived Address Creation)

•

Distributing SSTs to MWALs after they’ve been created

•

Indicating the settlement of trades (see Settlement of Trades)

•

Transferring SSTs between GWALs (at the same or other Clearing Firms)

•

Granting account type to new PWALs

•

Transferring SSTs to PWALs

•

Receiving transfer of SSTs from a PWAL (to their GWAL and indicating settlement to the relevant MWAL addresses)

ATS

The ATS writes information about executed trades to the Prometheum Blockchain for the purpose of public verification of settlement information written by a Clearing Firm. This information is only required to be able to publicly prove that the total indicated settlement for a trading session matched the total indicated trades for that same session. The information written about executed trades must not include any ATS-, Broker-Dealer- or Clearing Firm-specific or non-public information.

An ATS will interact directly with the Prometheum Blockchain by:

•

Obtaining GWALs (by having addresses granted the appropriate type by Prometheum)

•

Calling Smart Contract methods on the applicable SST contracts to indicate that a trade was executed

Issuance Platform & Transfer Agent Services

The Prometheum Issuance Platform provides the primary public interface to investors interested in SSTs. It also provides the onboarding and SST creation processes used by new issuers.

The Transfer Agent Services are a part of the Prometheum Issuance Platform intended to provide issuers with information required (including current owners of an SST) for regulatory purposes.

The Transfer Agent Services system will run nodes on the Prometheum Utility Blockchain to read data from events relating to the transfer of SSTs between PWALs

The Transfer Agent Services system will run nodes on Core chains to read data from events relating to the transfer of SSTs between MWALs. This is combined with separate (non-blockchain) data received from Broker-Dealers about which MWALs belong to which investors.

For the purpose of accounts and permissions, the Issuance Platform is effectively a “system” user. It is managed and operated directly by Prometheum. It does not hold GWALs, nor can it hold SSTs or interact with SST (Core or Utility) Smart Contracts. It does create and update a register of SST contract addresses.

The Issuance Platform will interact directly with the Prometheum Blockchain by:

•

Creating SST Smart Contracts on a Prometheum Blockchain Core chain and Prometheum Utility Blockchain

•

Providing distribution information (a holding address) during the contract creation process

•

Running a node on the Prometheum Utility Blockchain to read data from events

•

Assembling SST Smart Contracts from templates

Broker Dealers

Broker-Dealers provide the interface between users/investors and the ATS and Clearing Firm. The Broker-Dealer doesn’t directly manage any SSTs but they do interact with the Prometheum Blockchain in order to initiate requests from investors (to create PWALs, to transfer SSTs to PWALs) and to provide appropriate (off-chain) due diligence as required by the Clearing Firm (during transfer of SSTs to and from PWALs).

The Broker-Dealer only communicates with the Clearing Firm based on account identifiers and does not provide personal information about investors to the Clearing Firm via the Prometheum Blockchain.

A Broker-Dealer will send information about investors and investor balances of SSTs in MWALs to the Transfer Agent services part of the issuance platform. This is not done with data from, or via the Prometheum Blockchain. The Broker-Dealer generates this information by requesting or verifying account balances with the Clearing Firm. The Broker-Dealer cannot see the root MWAL address for an investor/account.

A Broker-Dealer will interact directly with the Prometheum Blockchain by:

•

Obtaining GWALs (by having addresses granted the appropriate type by Prometheum)

•

Calling Smart Contracts to initiate multi-stage approval processes at the Clearing Firm (e.g. transferring SSTs to a PWAL)

•

Interacting with multi-stage approval processes that it has initiated (e.g. indicating that it has completed due diligence on a transfer of SSTs to a PWAL)

•

Interacting with multi-stage approval processes initiated by the Clearing Firm (e.g. receiving SSTs from a PWAL)

A Broker-Dealer will indirectly interact with Prometheum Blockchain by:

•

Requesting the registration of approval addresses for the applicable GWALs at their Clearing Firm (so that the Broker-Dealer can participate in multi-stage approvals)

•

Sending PWAL creation requests to a Clearing Firm (the Broker-Dealer receives the request to grant a PWAL from an account holder and sends it to the Clearing Firm off chain with the applicable account identifier)

Issuer

An Issuer works with Prometheum and uses Prometheum’s Issuance Platform to create their SST and offer it for sale to the public.

The actual SST creation process is automated and managed entirely by Prometheum’s Issuance Platform.

An issuer may also be a Dapp Creator (i.e. they deploy Smart Contracts directly to the Prometheum Utility Blockchain to provide functionality to their investors/users).

It is likely that most Issuers will also be Dapp creators (see Dapp Creator). It is also likely that Issuers will hold one or more PWALs, which they may use to transfer their own SST to an MWAL.

If an issuer does hold SSTs in a PWAL, they will interact directly with the Prometheum Blockchain by:

•

Calling methods on Smart Contracts on the Prometheum Utility Blockchain (e.g. to transfer to a MWAL)

An Issuer user will interact indirectly with the Prometheum Blockchain by:

•

Creating an SST (via the Issuance Platform)

•

Accessing Transfer Agent Services information (via the Issuance Platform)

•

Creating a PWAL (via their Broker-Dealer)

•

Transferring SSTs to their PWAL (via their Broker-Dealer)

Investor

An investor is a person, company or entity that seeks to purchase an SST as an investment. This may be as part of an issuance or on the secondary market facilitated by Prometheum’s ATS.

Dapps users may also be investors.

A Dapp user may receive payment for services via a transfer of SSTs to their PWAL. They cannot trade these SSTs on the secondary market without first transferring them to their MWAL via their Broker-Dealer.

A Dapp user will interact directly with the Prometheum Blockchain by:

•

Calling methods on Smart Contracts on the Prometheum Utility Blockchain

•

A Dapp user will interact indirectly with the Prometheum Blockchain by:

•

Creating a PWAL (via their Broker-Dealer)

•

Transferring SSTs to their PWAL (via their Broker-Dealer)

Dapp Creator

A Dapp creator is similar to a Dapp user, but also creates contracts on the Prometheum Utility Blockchain to serve some application purpose.

The Smart Contracts deployed by a Dapp Creator may implement interaction with other public blockchains. For example, they may deploy a bridging contract to allow them to deploy functionality to another chain:

(Image)

Dapp deploys bridge contract to Prometheum Blockchain Utility Chain to allow interaction with a separate chain with a different payment mechanism

A Dapp creator will interact directly with the Prometheum Blockchain by:

•

Creating Smart Contracts on the Prometheum Utility Blockchain

•

Calling methods on Smart Contracts on the Prometheum Utility Blockchain

A Dapp user will interact indirectly with the Prometheum Blockchain by:

•

Creating a PWAL (via their Broker-Dealer)

•

Transferring SSTs to their PWAL (via their Broker-Dealer)

Appendix 2 –Processes and Integration Examples

Creating an SST

•

All parties (Issuer, Placement Agent, Escrow Bank, Broker Dealers, Clearing Firm, Prometheum) – provide required information for a complete issuance

•

Issuance Platform - Creates SST contracts on Core and Utility chain (leaving the SST at the Clearing Firm’s holding GWAL) and adds to the SST register of SST/addresses

•

Broker-Dealer - Provides information to Clearing Firm about account balances

•

Clearing Firm - Distributes SST to MWALs using distribute method of applicable SST Smart Contract

•

All parties – complete multi-stage approval upon distribution

•

SST Smart Contract – creates SST in the MWALs of the owning parties

Transfer to PWAL (with cold storage examples)

An example end to end process for transferring to a PWAL that incorporates a typical Clearing Firm offline/cold storage signature would be:

•

Dapp user / Investor - Obtains sequence/nonce from Prometheum Blockchain Utility chain

•

Dapp user / Investor - Requests transfer via Broker-Dealer

•

Broker-Dealer - Initiates process by calling method on applicable SST smart contract

•

Smart Contract – sets up multi-stage approval process ready for multi-party due diligence and offline/cold signatures

•

Broker-Dealer - Completes due diligence and approves first stage of multi-stage approval

•

Clearing Firm (operations wallet) - Performs due diligence

•

Clearing Firm (operations wallet) – Prepares confirmation for offline/cold signature

•

Clearing Firm – Physically transports confirmation information to offline/cold storage location

•

Clearing Firm (cold storage wallet) – Digitally signs confirmation and prepares movement back to operations

•

Clearing Firm (operations wallet) – receives signature from offline process and submits to smart contract

•

Smart Contract - Transfer contract completes and decrements GWAL balance

•

Clearing Firm - Calls Adjust Balance (from GWAL) on Prometheum Utility Blockchain for PWAL

•

Clearing Firm - Prepares settlement call information to reflect reduced balance in MWAL

Transfer to MWAL (from a PWAL)

An example end-end process of a user moving an SST from a PWAL on the Utility chain to an MWAL on a Core chain:

•

Dapp user / Investor - Calls transfer to MWAL method on Prometheum Utility Blockchain (locks up SST in PWAL)

•

Clearing Firm - Observes request (application layer tool) and initiates receive from PWAL process

•

Broker-Dealer - Completes due diligence; indicates approval via multi-stage process

•

Clearing Firm - Performs due diligence and offline/cold storage stages of approval process (similar to example in Transfer to PWAL)

•

Clearing Firm – Calls complete or cancel on Prometheum Utility Blockchain to adjust balance (if complete) and release/remove “locked” SST in PWAL

•

Clearing Firm - Transfer contract completes and increments GWAL balance on Core chain

•

Clearing Firm - Prepares settlement call information to reflect changed balance in MWAL *1 to be settled during upcoming settlement

Create a PWAL

This process does not start on the Utility chain (i.e. in a Smart Contract) as if the user has no other PWAL they can’t pay the transaction fees on the Prometheum Utility Blockchain. Generation of key pairs does not require a transaction and as such can be done by the user before they have SSTs on the Prometheum Utility Blockchain.

Similarly when a user wants to transfer SSTs to a PWAL they do so by requesting this with their Broker-Dealer, who initiates the process on a Prometheum Blockchain Core chain.

•

Dapp User / Investor - Generates a private/public key pair compatible with the Utility chain

•

Dapp User / Investor - Sends the address from this key pair to their Broker-Dealer with a request to create a PWAL for their account

•

Broker-Dealer - Provides request (off-chain) to Clearing Firm with account identifier

•

Clearing Firm - Creates PWAL account type for address (via Smart Contract call) and links (in its own records) that PWAL with the account identifier and MWAL for that account

Prometheum, Inc. Disclaimer

No money or consideration is being solicited by the information in this Whitepaper or any other communication and, if sent, money will not be accepted and will be promptly returned. No offer by a potential investor to buy our securities can be accepted and, if made, any such offer can be withdrawn before qualification of Prometheum’s Reg A+ Offering by the SEC. A potential investor’s indication of interest does not create a commitment to purchase the securities Prometheum is offering. Any such indication of interest may be withdrawn or revoked, without obligation or commitment of any kind, at any time before notice of its acceptance is given and all other requirements to accept an investment from a potential investor are met after the offering qualification date.

The Company’s Reg A+ Offering, after qualification by the SEC, will be made only by means of the Offering Circular. Any information in this White Paper or any other communication shall not constitute an offer to sell or the solicitation of an offer to buy, nor shall there be any sale of these securities in any state or jurisdiction in which such offer, solicitation or sale would be unlawful prior to qualification for sale as provided in Regulation A+ in any such state or jurisdiction.

You may obtain a copy of the Preliminary Offering Circular and the Offering Statement in which such Preliminary Offering Circular was filed with the SEC by visiting:

https://www.sec.gov/cgi-bin/browse-edgar?company=Prometheum&owner=exclude&action=getcompany

All information contained in this document is subject to change.

Introduction	3
What are Tokens?	3
What are Blockchain Securities?	3
What is a Smart Security Token?	4
Varying Regulatory Requirements	4

Core Concepts	5
Custody	5
Multi Chain Design	5
The Utility Chain	6
The Core Chain(s)	6
US Core Chain example	6
Multi-jurisdiction, Multi-core support	7
Prometheum and Public Chain Transfers	8
Shared Contract Layer	9
Multi-Stage Approvals	9
Cold Storage	10
Public Verifiability	11
Composable SSTs	12
Payment by Ember	12

Systems	12
Underlying Blockchain	12
Wallet Structure	13
Personal Wallets (PWALs)	13
Master Wallets (MWALs)	14
Management Wallets (GWALs)	15
Auction System	16
Participant Selection	16
Activity Initiation	17
Auction System for Validators	17
Issuance Process and Transfer Agent Systems	19