Eris:db is an advanced permissionable blockchain client that features various account types, which are essential for creating a typical enterprise-grade proof of concept (POC). The document outlines four typical account types: administrator, developer, validator, and participant, detailing their roles and permissions, as well as the requirements for creating a blockchain. Additionally, it emphasizes the flexibility of eris:db's permissioning system, allowing for custom account types and fine-grained control over capabilities.

1. eris:db
Permissioning and Account Types

2. Introduction
eris:db is the most advanced permissionable blockchain client currently in the open source
market.
The advanced nature of eris:db also brings a threshold level of complexity which must be
handled in order to reap the benefits of the system.
This deck will cover typical account types, how these typical accounts work together to
formulate a typical enterprise grade POC, and finally, advanced account types.

3. Four Typical Account Types For Enterprise POC
While eris:db offers a very broad range of account types and permissions, a typical enterprise grade POC will
include the following four account types:
1. Administrator accounts. Typically the head of innovation or equivalent, along with the head developer
from the integrator. These accounts can do anything and everything on the chain, use with caution;
2. Developer accounts. Typically a range of developers will be given accounts which allow them to take
most of the actions necessary to build out the smart contract application;
3. Validator accounts. Typically running within a data center or in the cloud, these accounts typically only
have responsibility for validating and “moving the chain forward”; and
4. Participant accounts. Typically these would be other participants in the POC who only need limited
permissions in order to interact with the application rather than to build it, such as sponsoring
business unit.
N.B., instead of “nodes” we use the term “accounts” but the idea is roughly analogous

4. Four Typical Account Types For Enterprise POC
Account Type Who Usually Given? How Many Usually Given?
Administrator Accounts ● Client Lead Dev
● Integrator Lead Dev
● Eris Account Dev (if needed)
2-3
Developer Accounts ● Client Dev Team
● Integrator Dev Team
5-7
Validator Accounts ● Data Center or Cloud Nodes 7 (tolerates 2 down nodes)
to
10 (tolerates 3 down nodes)
Participant Accounts ● Client biz unit
● Client lab/innovation hub
15-20

5. What’s Needed to “Make A Chain”
When anyone makes (or instantiates) an eris:db chain, what they need is to create a small table similar to
the one on the previous slide which outlines the account types they need (note the previous two slides are
typical examples rather than requirements) and the number of each account type.
Then whomever is instantiating the blockchain needs to either generate or gather public keys for each
account. Eris always recommends that all users generate their own keys.
Finally, they will need to give the account types their proper permissioning and formulate an accounts.csv
which has the public key, amount of tokens, and permission level of the account as well as a validators.csv
which contains analogous information for the validators.

6. What’s Needed to “Make A Chain”
Public Key Tokens Name Perms
What a typical accounts.csv looks like.

7. Typical Permissioning Specifics
Permission Administrator Developer Validator Participants
root Y N N N
send Y Y N Y
call Y Y N Y
create_contract Y Y N N
create_account Y Y/N N N
bond Y N Y N
name Y Y N Y
N.B., for more info please see Eris’ Documentation

8. Typical Permissioning Specifics
Permission Administrator Developer Validator Participants
has_base Y N N N
set_base Y N N N
unset_base Y N N N
set_global Y N N N
has_role Y Y N Y
add_role Y Y/N N N
rm_role Y Y/N N N
N.B., for more info please see Eris’ Documentation

9. Do We Have To Use the Typical Account Types?
No.
eris:db permissioning uses capabilities based permissioning where all of the capabilities included in our
permissions documentation can either be turned ON or OFF for any given account. This allows very fine
grained control over accounts and what they are able to do within the network.
Yet, it, admittedly, also adds a bit of complexity into the system. We use the Four Typical Account Types as
a way to reduce the complexity for a typical POC. However, we have built in flexibility to deal with many
more account types.