Digital Infrastructures for Decentralized Organizations
In this section we review the information on digital infrastructures that are relevant to understand how technology may improve efficiency of decentralized organizations. A general discussion on the appropriate a digital infrastructure to be considered to make the decentralized organization more efficient must necessarily start from the selection of the most appropriate architecture. This choice will depend fundamentally on organizational and economics motivations.
In particular, we introduce the basic information that is relevant to become familiar with the, nowadays widespread notion of Decentralized Autonomous Organization (DAO) as commonly perceived in relation to thos that have been developed relying on permissionless blockchains and in particular on the Ethereum blockchain. This specific analysis will be focused on the digital infrastructure characteristics and, given the large amount of available material, will only review those sources that are relevant to the MUSA research project at hand. In particular, as a last discussion topic, we review the implementation of a project dedicated to implementing a supply chain finance solution relying on the use of a public DLT.
Introduction
A DAO is a computer program that runs on a distributed peer-to-peer network. They are controlled by communities of online agents that collaborate and operate without the need for a central governing body. DAOs are created to operate without human involvement. This is done by transcribing organizational processes and governance protocols into algorithms. The code runs on a digital distributed ledger known as blockchain.
In centralized organizations, the power and authority to make decisions is held by executive members or top-level management. This creates a hierarchy decision-making structure where the top-level employees control and direct the organization. On the opposite end of the spectrum are decentralized organizations where decision-making is delegated and is flexible. This means that executives assign part of their responsibilities to management and communicate often to oversee processes.
A DAO is a type of decentralized organization; however, the key innovation is that DAOs are autonomous and can exist only relying on a digital infrastructure. DAOs rely on distributed ledger technology to record and enforce decisions and organizational processes. This could include aspects like issuing shares, appointing a CEO, voting on proposals, and paying salaries.
The foundation of DAOs are smart companies or agencies. A smart agency is an atomic governance unit that is managed and operated with smart contracts. Agencies should have their own tokens, reputation systems and governance system. The token is associated with the company’s resources, the reputation is based on the credibility in company matters and the governance system consists of the bylaws that are written and executed in smart contracts.
KEY TAKEAWAYS
- A decentralized autonomous organization is an entity structure in which token-holders participate in the management and decision-making of an entity.
- There is no central authority of a DAO; instead, power is distributed across token-holders who collectively cast votes.
- All votes and activity through the DAO are posted on a blockchain, making all actions of users publicly viewable.
- A DAO must ensure security is prioritized, as exploits can leave a DAO drained of millions of dollars of its treasury savings.
Although the ecosystem is heterogenous and evolving, DAOs can be classified in relation to three distinguishing characteristics:
- Use of blockchains, digital assets and related technologies
- Allocation and coordination functions
- Governance
In practice, different DAOs will adhere to these criteria to varying degrees. For example, some DAOs decentralize governance more extensively than others. Likewise, as a DAO evolves, the degree to which it adheres to each dimension may change as well. Below a classification of the basic properties that have to be considered.
| Governance Factors | Hierarchical Organisations | DAOStack |
| Managing Stakeholders | Different strategies are used to manage internal and external stakeholders. | Stakeholders exist within the DAO as agents with influence weightings. Stakeholders can vote on certain decisions in the organisation. |
| Stakeholder Needs | Stakeholder needs can conflict, but they are often used to form organisational objectives. | Stakeholder can create proposals documenting their needs. These proposals must abide by governance protocol’s permissible actions. |
| Organisational objectives | Objectives are based on a flexible framework that includes principles such as:
· Alignment of IT and business strategy, · Managed IT-related business risk, · Delivery of IT services in line with business requirements. Using tacit and organisational knowledge, it is easier to identify high level objectives. |
Objectives are programmed into the governance protocol. E.g. Majority voting for Profit margins, Voting on Service Level Agreements, Assigning Key Performance Indicators.
High level objectives must be transcribed into measurable tasks that can be codified in the system. |
| Business Intelligence (BI) Tools | Making decisions requires a balance of quantitative and qualitative information. Although BI tools can be used to form decisions decision makers also rely on tacit knowledge, interpretation of hard data, intuition, and technical skills.
The responsibility and accountability of decisions are held by single individuals. E.g. CIO or CTO. |
BI tools can be built as an application layer on top of the blockchain. However, decision-making power is distributed among agents who vote on proposals.
Tokens like reputation or stake can be used to quantify decision-making power . Voting can be incentivized. Decision are automatically executed when there is a majority vote. |
| Providing Value to the business | According to COBIT 5, Directors provide value by controlling, monitoring and evaluating an organisation. This requires them to make informed decisions and take accountability for those decisions. | Value lies in the automated decision making, automatic execution of these decisions, transparency, accuracy, resilience and meritocracy. Accountability of decisions is spread across voters. |
| Compliance to IT rules and regulation | Internal and external auditors can be appointed to examine and analyze compliance. This process does not severely interfere with organisational activity. | IT rules and regulation are programmed as schemes in the smart-contract framework of DAOStack. Protocols must be upgraded when external or internal laws have changed. This may affect the performance of the DAO. |
| Managing Risk | Directors are expected to recognize pain points and triggers related to IT risk such as data loss or project failure. All documented risks must be controlled at an acceptable level. | Pain point and triggers can be incorporated into the main protocol. If they occur, directors can be automatically notified. |
| IT Security | Requires collaboration from all levels of an organisation and involves both IT and non-I T departments. IT Security policies are set by Board members, interpreted as managerial procedures and formed into operational processes. | Security risks should be assessed at inception in DAOs. It is difficult to refactor code after the DAO has been deployed. The advantage is that individuals cannot compromise the system. The disadvantage is that protocols may be “technically” correct by can be bypassed by manipulation. |
Examples of implementations
Given the myriad of ways that a DAO can onboard new participants and structure its internal workings, the following examples are some of the more common methods and resources implemented today:
Onboarding participants
Token membership
Token-based memberships are usually permissionless (openly accessible) to anyone and everyone - depending on the token used. Although some are created in the form of governance tokens that can be traded openly on decentralized exchanges, others have to be earned through providing services like liquidity or other work-related offers. Regardless of how they are granted or purchased, holding the token is often enough to allow members to vote on proposals and access additional aspects or locked components of the DAO.
Share-based DAOs, on the other hand, are more regulated but still open to the public. In a share-based DAO, prospective members can submit proposals to join, usually outlining a specific service or skillset to receive tokens in exchange for the work on offer. As with the dynamics of governance tokens, shares can also provide members with direct voting rights and proportional ownership, giving people the freedom to exit with their treasury share at any time. These share-based DAOs are usually used for closer-knit human-centric organizations like charities, worker collectives, and investment clubs with a general focus on governing protocols and tokens.
Voting tokens
A token can be used to make a user part of a DAO. It can be every token DAO recognize as membership, normally a fungible token is used, but there are some examples that uses non fungible tokens. When using a fungible token, an important part of this token should be the voting mechanism, including delegation powers.
You can find a lot of example in DAO’s implementation, one of the most used is https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/ERC20Votes.sol
Normally a voting token can be bought or airdropped like a normal token. Every member should receive voting tokens into their wallet as a mean to vote on DAO’s proposal.
Governance
Governance smart contract is the engine that makes DAO decide how to emit proposals, how long a proposal can stay open and what the results are, along with all other features a DAO would like to setup and discuss by their members.
An example on how a governance smart contract can be implemented can be found at https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/Governor.sol
An example on how a simple DAO can be built is: https://wizard.openzeppelin.com/#governor were a lot of different parameters can be set independently.
Proposals
Proposals should be published on the blockchain via the governor smart contract. An example could be find here: https://etherscan.io/tx/0x59d1648c1ed1dc60c3dff94ce480f87c562e4810edb647401922f7d53fc7e380. Proposal could be also stored on IPFS (https://snapshot.mypinata.cloud/ipfs/bafkreic3wpbovzvzvgor2fwqxwyad7z5quurtwyl4jub6pkparvtfhxmum) for future reference.
Governor smart contract could assess what minimum amount of voting tokens can promote a proposal, and the same contract set voting start and end operations, which should be the minimum quorum, and all other aspect related to the proposal itself. It also should give the results at the end of voting period.
Casting votes
Votes can be on chain or off chain (https://snapshot.org/#/), depending on how DAO planned to make them happen. On chain votes are quite easy since voting token has this capability, while off chain votes must be managed by a backend and assured via cryptographic signature.
Proposals implementation
Based on votes, a DAO should implement approved proposals according to what the proposals concern and reject not approved proposals.
A Public Blockchain implementation of Supply Chain Finance solutions
This section is based on the academic contribution:
Chen, C.-P.; Huang, K.-W.; Kuo, Y.-C. Conditional Token: A New Model to Supply Chain Finance by Using Smart Contract in Public Blockchain. FinTech 2023, 2, 170-204. https://doi.org/10.3390/fintech2010012
Introduction
Blockchain solutions are characterized by the fact that the recorded peer-to-peer information cannot be forged and tampered with, and are easy to trace, in the same time having lower operational risks than traditional supply chains, and that suppliers will benefit from blockchain-based supply chain financing.
Supervisory agencies, international institutions, and scholars study affirm that the application of blockchain in supply chains may improve information sharing, it can facilitate international payments, automate transactions and improve access to funding opportunities.
The adoption of blockchain-based Supply Chain Finance (SCF hereafter) solutions still requires the solution of these three issues.
- current research focuses on the passive nature of using the blockchain in log records, which fails to use the advantages of smart contract programs to issue and operate tokens.
- the application of blockchain in SCF mostly adopts permission-based (or membership-based) consortium chains, which limits the inclusiveness, and the credibility of the system because of the limited number of nodes.
- the feasibility of blockchain in SCF, including its cost-effectiveness and legal nature.
Blockchain and Smart contract
There are three types of blockchain systems, from the most decentralization to the least would be public blockchain, consortium or hybrid blockchain, and private blockchain.
Smart contracts are application that are self-executing, tamper-proof, and enforceable, and can be used in a wide range of applications, from supply chain management to financial services.
Ethereum is currently the most popular platform for developing smart contracts, as well as the EVM, Ethereum Virtual Machine.
Despite their many benefits, smart contracts face several challenges. One of the main challenges is the lack of standardization. Another challenge is the complexity of smart contracts. Smart contracts can be difficult to write and understand, which can make them vulnerable to errors and bugs.
Conditional tokens
In practice, two types of Conditional Tokens (CT herafter) are used, one is an obligation-type, the other is a right-type.
For the obligation-type, there are two processes of issuing (aka tokenized collateral), with the first process locking-in collateral. Then, as the second process, CTs backed by collaterals are minted.
There are two processes of issuing right-type CT, depositing fiat currency to receive account tokens (aka collateral in obligation-type), then transfer account tokens to the “lock-in” address, followed by deciding the “rights”. The first process can be done by an application program interface (API) from a third-party payment or bank service. The smart contract will issue the account tokens to represent the fiat currency after a successful deposit.
Different type of CTs are explained in the following 2 pictures:
Obligation-type CT:
- collateral tokens are held in smart contracts
- verification from a third party is required
- verification completed
- smart contract issues/mints a predetermined number of CTs
The protocol of “lock” or “unlock” can apply or revise ERC-1132.
Issuing right-type CT:
- the supply side transfers account tokens, locks them into the smart contract
- applies the mint function of smart contract to issue the conditional tokens
To summarize the 2 types of CTs, the use of CT needs to fulfill (exercise) the agreed obligations (funding rights) at the same time.
The obligation-type CT is divided into three types:
- inventory CTs (inventory backed),
- pledge CTs (backed by something other than inventory)
- margin CTs (cash backed).
Obligation-type CT is a divisible Line of Credit Mortgages or a CT equal to a mortgage with a one-unit limit. The maximum amount of mortgage rights is the number of CT’s issued after the mortgage is created.
The funding right-type CTs are called investment CTs. The fund providers can decide on a certain set of conditions, such as the minimum rate of return, and determine the conditions once more through matching, or directly select and agree on the conditions in advance. Therefore, the conditions can be an investment tranche with different returns, with each CT acting like a divisible fixed-income bond.
Operations on CTs are summarized in this way:
| Functions | Inputs | Descriptions |
| Balance T | a | The balance of CT for address a |
| Mint 𝜇 | a, m, E | Mint amount m of CT with condition set E to the address a |
| Exchange Π | a, 𝛽, m | Exchange amount m of CT to amount 𝛽𝑚 currency token X for address a |
| Transfer 𝜎 | a, b, m | Transfer amount m of CT from address a to address b |
| Modification Ψ𝑖 | a, E,𝐶′𝑖 | Modify the ith condition 𝐶𝑖 to 𝐶′𝑖 in condition set E for address a |
| Burn 𝜐 | a, m | Burn amount m of CT from address a |
The Application of CT to SCF
Loan or advance payments
Traditionally, the buyer pays in advance for the goods, however has not yet received the goods for sale or needs an early planning of its sales, resulting in a funding gap, therefore, it secures it financing by using “future trade receivables” as guarantee.
If CTs are used, they can replace the collateral agreed upon by both parties as shown in Figure 4, because we assume core company has proof of credits already. CT is provided at the same time the sale happens, helping the dealer solve the funding problem caused by repeated pledges.
On the other hand, if the seller receives a purchase order for goods, but has not yet received cash before the product or delivery is finished, the situation results in a gap in raw material funds, leading to the purchase order being similar to the “future trade receivables”.
Purchase order financing is based on the demand for funds in the entire process from placing an order until payment is received. The “future trade revenue“ of the order is used as the source for loan repayment. The deposit can be either cash or currency tokens. Manufacturers who accept the CT can exchange it for capital, or transfer it to other manufacturers, basically solve and mitigate the risk of multi-level information transmission of purchase order financing.
Purchase of Account Receivable
After upstream companies (or exporters), being the sellers, complete the order and ship the goods to the core company (or importer), while the buyer did not pay upon delivery, it will create accounts receivable (AR) that are received by the seller. If AR is sold directly, it is called factoring, with the fund provider being called factor.
CT’s are used as accounts receivable or as a payment instrument of the buyer, so that the sellers (upstream) can sell the CT’s to fund providers. Sellers can also use the tokens as AR or payment instruments when dealing with higher tier manufacturers, and can modify the conditions of the CT to reflect time value (discount) and the respective expiration date, waiting until expiration date, or to show the CT to claim payment for the goods. The transfer process of the CT will be recorded in the blockchain where anyone can verify it and thus know whether the information is correct or not.
Inventory Financing
CT is obtained by using the inventory as a collateral, and it requires to be verified and evaluated before issuing. The core company can use the CT for itself or transfer the CT to other companies.
Similar to borrowing and lending platforms, many example in DeFi space.
Peer-to-Peer/Person-to-Person (P2P) Financing
As in centralized platforms, the scheme is given by:
System Design and Implementation
SCF System
An example of implementation is represented by this picture:
Blockchain and Smart Contracts
Unfortunately, contracts are not verified, so no further analysis can be performed. However
- Currency token (XT): https://goerli.etherscan.io/address/0x601cdEcd235a43F9181A8213B2a664A9703a742e
- CT operations (obligatory-type CTs): https://goerli.etherscan.io/address/0xee02f04a9b5c500dc915d54e1fce79d016795526
- Verification: https://goerli.etherscan.io/address/0xf2b706d5e3c828D592Db44980Fbd8899D6490938
It seems they released an ERC1155 token with ID 1 (similar to a NFT)
- Investment and profit distribution: https://goerli.etherscan.io/address/0xf788E3cEdfc6E66Cd553CE9636d418F141992DB2
- Channel financing: The core company will mint obligatory-type CT with specified conditions on the blockchain to provide guarantee and transparency, then the receiving downstream company can use it for further finance or transfer.
- Accounts receivable financing: The obligatory-type CTs are minted to reflect the time value, therefore discounts are applied in the financing process.
- Inventory financing: The obligatory-type CTs are authorized by a third-party institution. The inventory is used as the collateral which will be liquidated after a breach of contract, then the funding provider(s) would be able to retrieve payback from the inventory liquidation amount.
- Investment service: Natural person or juridical person can be secured via right-type CTs after providing funds. Every right-type CT offers different annualized payment yield (APY) by investing in different tranches for different ranking of claims.
- Transfer and conversion of CTs: CTs can be transferred via blockchain as the debt transferring. Companies will be able to manage their obligatory-type CT received from the previous company to conduct risk-control more easily, meanwhile to maximize the efficiency of the supply chain.
- Finance management: Profit sharing agreement between core company and investors is programmed in smart contract.
Methodology comparison.
| Items | Traditional | Consortium Tokens | Conditional Tokens |
| Tier | 1 + 1 + 1 | N + 1 + N | N + 1 + N |
| Safety (consensus) | centralized database | asymmetric cryptography | asymmetric cryptography |
| Cash flow transparency | tier 1 | N + 1 + N | N + 1 + N |
| Credibility | single financial institution | permissioned member | unspecified person |
| Flexibility | law | middle | high |
| Inclusive | law | middle | high |
Final Considerations
Security tokens are all those who respond to Howey's test (1946) which defines a security in this way: if a person invests his own money in a common project and is expecting profits deriving exclusively from the efforts of the promoter or a third party, then this is automatically a security. SEC is getting tangled with this definition, and lately it defined many cryptocurrencies as securities, excluding Bitcoin and Ethereum, and some discussions are ongoing.
If a tokenization project has to deal with "financial instruments", then it is dealing with security-type instruments. These tokens cannot be freely transferable to subjects not previously identified, and they can be transferred only via specific roles, that must be “centralized", meaning that all functions implying a transfer action (like mint, burn, transfer, and so on) has to be modified to reflect this request.
The only relevant EVM standard is https://erc1404.org/, which is backwards compatible with ERC20 but with some limitations on transfer functions and restrictions. The conditional token described in the article therefore does not have the necessary limitations, and I don't think it can be used in a security token project. The workflows described in a good way, and other further customizations that can be inserted in a security token smart contract.
Useful information on DAOs available on the Internet
The following links provide a vast amount of information about the existing DAOs:
- DeepDAO: https://deepdao.io/organizations Leading discovery and analytics engines for DAO ecosystems. It aggregates,displays, and analyze a rich view of up-to-date token, treasury, governance, and membership data for over 2,000 DAOs, on multiple blockchains and governance platforms.
- Coinbase resource: https://cointelegraph.com/learn/types-of-daos A useful classification and discussion about the basic steps to be done in order to create a DAO.
- J Internet Serv Appl 12, 9 (2021). https://doi.org/10.1186/s13174-021-00139-6 Faqir-Rhazoui, Y., Arroyo, J. & Hassan, S. perform a comparative analysis of the platforms for decentralized autonomous organizations in the Ethereum blockchain.
