With the basics of Corda under your belt, we will take you to the next level of your Corda distributed application (CorDapp). In this boot camp we’ll help you learn how to use accounts capabilities. Accounts give a developer the ability to support many identities within a single node. This capability helps Corda scale to support many end-users who may not require a dedicated node.

1. Account Workshop

2. Questions we want to answered [Not shown]
• Where is Account stored?
• Who is really signing the transaction when I am an account?
• Am I visible to the participants on the network?
• Does the other participants required to have account, if one of the participants want to use
account.
• How is Account mapped/linked with the state?
• What are the problems accounts is trying to solve?
• Can I easily migrate from node based model to account based model and again migrate
from an account based model to a node based model?
• Typical life cycle of an account?
• How can offchain identity be mapped to onchain accounts identity?
• What are the typical use cases when we would want to use accounts?
• Roadmap of accounts
• Can tokens and accounts be integrated

3. The Problem We Had…
• Corda was not designed to deploy and operate by individuals and small businesses. (such
as, a local corner candy store or my friend Roger)
• Most Cordapp developers will represent their customers. When the number of customers
goes up, the total cost of spinning up a node for every customer becomes costly.

4. Introducing Corda Accounts
So that:
• A Corda node can host multiple “individuals/small companies” who wants to play a role in a
larger blockchain system. [Increase scalability]
• Consortium can “represent their customers” via accounts, while only spinning up minimal
numbers of nodes depends on the use-case. [Reduce operation cost]
An accounts library allows a Corda node operator to split the
vault into multiple "logical" sub-vaults.

5. High Level Pictorial Explanation…
NODE A VAULT
ACCOUNT ONE ACCOUNT TWO
KEY MANAGEMENT SERVICE
Stores key pairs
KEY HASH1 : ACCOUNT ONE, NODE A
KEY HASH2 : ACCOUNT ONE, NODE A
KEY HASH3 : ACCOUTN TWO, NODE A
KEY HASH4 : ACCOUNT X, NODE B
IDENTITY SERVICE
NO ACCOUNT
Maps key pairs to node identities and account ids
Level 1
Level 2Level 3

6. Points to note…
• Accounts are not Corda Identities – they are a different representation of a collection of states
and public keys.
• Account creation, discovery will be implemented on the Cordapp level. (Not from the
network level)
• Vault isolation is not supported – all accounts share the same node service and keys are all
stored in the same key management service.
• Node operator will know it all.
• Standalone HSM private/public key management for accounts is not supported.

7. Pictorial Representation Of Accounts

8. Use-Cases…
• Host multiple customers per node
• Custody-like accounts, brokerage accounts, bank accounts, etc.
• Internal separation between departments of large companies
• Isolate sensitive information from non-involving departments.
• Massive adoption of 2C application
• private record per consumer.

9. Under the hood of accounts…
• AccountInfo & AccountService
• Life cycle of an Account
• Account APIs

10. AccountInfo & AccountService

11. AccountInfo & AccountService
Link: <Path of Account Repository>/workflows/services/AccountService.kt

12. Life Cycle of an Account (Part I)
Account creation & sharing with counterparties:
1. Create Account
2. Share AccountInfo with counter parties
In the flow:
1. Retrieve the account and request a new set of Public/Private key pair for the transaction
2. Request the signing keys from counterparty’s account.
3. Share the transaction’s output state with the counterparties if we expect the state will be used as an input
for any further transactions. [Optional]
4. Record the transaction to corresponded accounts in responder flow

13. Life Cycle of an Account (Part II)
Querying the Vault:
1. Create a new query criteria
2. Perform query to return all desired states for account with specified accountId

14. DOORMAN
NODE
Node / Party /
First Class Identity
Certificate generated and signed by
node and then signed by Doorman.
Used by node operators. Node
operators might be companies that
also participate in states on the
ledger. However, the state which
they participate in would only be
through accounts.
Account
A Party and label pair. Where Party
represents a host node and label
represents some Party/application
scoped identifier. There is also a
UUID which should be unique at the
network level. Labels are only
guaranteed to be unique at the node
/ Party level. However, when they
are coupled with a Party, they are
guaranteed to be unique.
ACCOUNT
NODE NODE
PUBLIC
KEY
ACCOUNT
IDENTITY
AccountInfo
Name: String
Host: Party
ID: UniqueIdentifier
PublicKeyToExternalID
When new PublicKeys are created
on the host node, they will be
allocated to the UUID for a particular
Account. As such, Accounts will be
associated to multiple PublicKeys.
This is how the node keeps track of
which states should be allocated to
which Account.
ACCOUNT
Services / CorDapps
When new PublicKeys are created
on the host node, they will be
allocated to the UUID for a particular
Identifiable. As such, Identifiables will
be associated to multiple PublicKeys.
This is how the node keeps track of
which states should be allocated to
which Identifiable.
ACCOUNT
ACCOUNT
ACCOUNT ACCOUNT
IDENTITYIDENTITY
Identity
Represents the identity of a “user”.
Identifiables do not have a Doorman
provisioned identity. Instead, they
only have an identity in the context of
a Party node (that does have a
Doorman provisioned identity).
These identities are, in effect, self
signed. Noes/parties can attest to the
claims made in the Identifiable state.
AccountInfos are ledger states so that they can be easily shared with other nodes.
Holistic view

15. Code Example
Let’s go to IntelliJ …

16. Try it Yourself
Java version: https://github.com/corda/samples-java/tree/master/Accounts
Kotlin version: https://github.com/corda/samples-kotlin/tree/master/Accounts
Supply Chain:
This CorDapp mimics a supply chain transaction, where the deal is incorporated among
different teams in the companies on both side of the trade.
Tic Tac Thor:
This CorDapp recreates the game of Tic Tac Toe via Corda. It primarilly demonstrates
how you can have linear state transactions between cross-node accounts.
Worldcup Ticket Booking:
This CorDapp demonstrates an ticket booking system with a collaboration of Corda
Account Libray and TokenSDK.