Model your organization on EOSIO blockchain

There’s one important feature of EOSIO software which is often neglected: hierarchical and flexible permissions system.

Any organization has roles and responsibilities, and certain people executing on behalf of these roles. There is always a formal or informal distinction between a person and a role.

It appears that many users don’t realize how easy and straightforward it is to reflect the organizational structure on the blockchain. Hierarchical permissions and multi-signature can do wonders.

Let’s have an example: a company BlockToo Inc. has a board of 5 executives, HR, purchasing department, and a warehouse.

Organization account: blocktoo

The main organization account blocktoo has owner permission that is only used for emergency recovery. So it’s set to a multisignature requiring 5 signatures out of 8 (5 executives, plus head of HR, head of accounting and head of IT).

The active permission of blocktoo does not bear any financial function, and it’s only used to manage additional permissions. So it’s set to a multisignature permission requiring 2 signatures out of 3: two HR employees and the IT manager.

The purchasing permission of blocktoo defines a list of users and a threshold that is required to spend money on production supplies. Let’s say the company policy is that every payment should be verified by at least two persons. The purchasing department consists of 7 employees, so the multisignature lists 7 personal accounts with their active permission and threshold of 2.

The whmng permission of blocktoo represents the warehouse managers. There are 3 managers each able to approve the work of warehouse workers, so the permission has threshold of 1 and 3 personal accounts.

The it permission of blocktoo represents the IT department. The department is responsible for updating the smart contracts, and requires 3 out of 5 IT employees to sign.

Purchasing department account: prc.blocktoo

prc.blocktoo is an account for spending on corporate purchases. The accounting department transfers tokens to it monthly according to the budget and company well-being.

Now is the important trick:

• prc.blocktoo@owner permission consists of only one permission blocktoo@owner, with weight of 1 and total threshold of 1.
• prc.blocktoo@active permission consists of only one permission blocktoo@purchasing, with weight of 1and total threshold of 1.

What does it result in? Now the purchasing department is able to spend tokens from this account. Each spending requires 2 signatures, because our active permission requires authorization of blocktoo@purchasing, which is in turn requiring two signatures.

So on every payment they issue an eosio.msig proposal (also the accounting software can create such a proposal automatically and inform all team members via corporate chat) and let a colleague review and co-sign it.

Warehouse smart contract: wh.blocktoo

wh.blocktoo is a smart contract for warehouse automation. Whenever a pallet of goods is arriving or leaving the warehouse. The worker is scanning its barcode and signs a transaction with their personal NFC chip. This transaction executes a corresponding action on the smart contract, registering the pallet and who has performed the acceptance or shipment.

wh.blocktoo@active permission is set to blocktoo@it, so that the IT department can perform the maintenance. The owner permission is set to blocktoo@owner.

The warehouse workers send transactions on their own behalf (e.g. john@active), and the contract verifies if the account belongs to a list of warehouse workers.

The warehouse managers need to verify and approve the work of the workers by the end of the day. The contract verifies if the approval action is authorized by blocktoo@whmng. Even that the permission requires only one signature, one of the warehouse managers is creating a proposal at eosio.msig, approves and executes it immediately.

Alternatively, the contract may keep the table of warehouse managers and check the approval authorization against this table. In this case, blocktoo@whmng permission is not needed.

Conclusion

This example aims to demonstrate that the organizational structure can be managed in a compact way: whenever an employee enters or leaves the company, the HR department needs only to update the permissions of the company account and the table of workers in the warehouse contract.

The concept of organization management can be extended further: there can be a separate contract which is only listing employees and their roles, and the warehouse contract would refer to its tables to check if a transaction submitter has the right role. In this case, other smart contracts can refer to this central table of user roles too.

The warehouse workers, in theory, could also be grouped into a separate permission on blocktoo account, and the warehouse contract would only require one single permission for pallets checkin and checkout. But then the smart contract does not have a possibility to verify which worker’s account has performed the job, so the bookkeeping would only be possible outside of the contract (for example, by processing the state history, we are able to see which signature was issued, and then associate the action with the worker). But if such verification is available to the smart contract, it can also use this information for various purposes. For example, transferring bonus tokens to the employee account.

EDIT1: the purchasing can also be served by a smart contract that manages spending limits and requires different levels of confirmations depending on the amount.

EDIT2: warehouse worker is a function that is linked to the RFID wristband or a badge, but not to a person. If someone quits or starts a new job, the badge is just handed over, so the administrative overhead can be brought to a minimum.