Wetonomy’s Building Blocks Overview

Wetonomy targets creating DAO-s easily and of course, with a bit of customization in mind. So, to follow the idea behind, we tried developing its architecture in the same direction — to be an extensible but solid, easy, but powerful tool to work with.

And to accomplish that we developed our own Smart Contracts framework ( StrongForce) so that we have the power to be as flexible and stable as possible. It is a .Net based Smart Contracts framework over Tendermint Consensus, which provides an engine for writing your own contracts in dotnet, enables message forwarding and control over the addresses that have the permissions to execute a particular action. Tendermint Consensus ensures that transactions will be recorded in the same order in every machine. Cosmos SDK presents the ability to scale up immensely through different blockchains and create “Internet of Blockchains”. Do not miss to check out StrongForce.

Once we laid down the basis with the contracts, we focus on the main building blocks in the Wetonomy’s architecture. A bit generally, but we can divide them into categories — Members (handle the logic behind having participants in the organization), Units of Work (track the progress/work) and Token Flow (control the complex logic for spreading the tokens generated by the units of work and the mechanism of High Risk Automated Debt)

Members

The idea of the classes related to the members logic is to handle all the actions a member or group of members could do. Each member extends the Contract class from the StrongForce:

Thus, each member has certain permissions, can receive&execute an action (depending on the permissions), or forward the message/action to the next contract that might have permissions to receive it. The logic for message forwarding is handled by a bullet (a concept we will dive into in another post, but with a couple of words — it marks the path of a message and if the target can handle it, then the bullet is taken).

The Member and MembersGroup classes in Wetonomy extend the functionality of Contract by additional specific info — name, group members, fieldLevels, etc. And the nest for all members is a MembersFactory that takes care of their generation.

Units of Work

The idea behind Units of Work is to be able to track the progress in the organization — how much work its participants do, validate it in case there are some rules set (for example maximum of 160 hours per week if that is meaningful for the group) and keep a history of the events.

Naturally, related to the Units of Work is the Task — a simple class that holds the information of … well — of a task — who created it (the issuer), who will take care of it (the assignee), what the stage is (not done, in progress, done, archived), etc. In case the task is a more complicated one — in the terminology of OKR (objective key results) — an Objective — it could have a collection of tasks that belong to it (once all those tasks are completed, the Objective is completed as well).

And of course, each task is associated with tokens. Once it is completed, they are transferred to the address of the assignee and can be dumped. In the case of an Objective, those tokens can be split through all those that participated in the finalization of the contained tasks.

Token Flow

Here the things get a bit more complicated as we need to ensure that all scenarios are covered — of course, minting and burning, but splitting the tokens as well. A TokenFactory takes care of creating the necessary managers — TokenManager, TokenSplitter, TokenMinter & TokenBurner — each of them performing the logic behind those actions.

As expected, a manager keeps track of the balances, mints, transfers and burns its corresponding tokens. Furthermore, implementing the ITokenTagger interface results in functionality to tag/specify each token. Thus, you can have specific ones into separate categories, differentiate them based on your needs and later pick them depending on their tag.

Each of the main blocks here (TokenSplitter, TokenMinter & TokenBurner) extend RecepientManager class (which is a Contract at the end of the day). Every recipient (address) can be added through the functionality of the base class, while each of the children handles the specific logic (mint, burn, split). The bonus with the splitter (as you probably can guess) is the functionality of separating the tokens and transferring them to the corresponding addresses (recipients).

Of course, there is a bit more craftsmanship behind all those classes and their implementation, but the main idea here is to get a slightly deeper overview of the architecture, but without too many details (well, for details — follow us, you’ll not be disappointed).

The whole pieces here should allow each organization to handle its members, track the work progress, generate inflation based on it and most importantly give back the ‘what’s-deserved-and-owned’ by the participants. And all of that automatically, without too much intervention and of course, without the need of trust, but rather just by doing what you have the power to — push the organization forward ❤

Originally published at http://blog.wetonomy.com on June 24, 2019.