Map

Organizations

Covenants ITEMS Equities NERV WIMD Doc Buidlerberg Discord Github The OS

On-Chain Organizations


On-chain organizations provide R&D infrastructure to build flexible and fully upgradable protocols by voting.

Equity Token: $BUIDL

Decentralized Without Compromise

The code of a DAO is owned by an off-chain entity, usually a development team or company. Control by token holders is always limited, if any is allowed at all; they can only ever govern inside fixed boxes with parameters defined and managed by supervising centralized parties. On-Chain Organizations, to the contrary, are owned exclusively by token holders. On-Chain Organization tokens are Ethereum Equities, the only sets of keys to the code, and control every single line. Governance is completely on-chain and, for the first time on Ethereum, decentralized without compromise.

Secure, Sophisticated Governance

On-Chain Organizations have microservice-driven cores. Holders can add, remove and edit any functionality by voting for atomic executions of code. This architecture enables simple yet sophisticated governance, using secure, battle-tested factory contracts that can be recycled and endlessly reappropriated by anyone for any purpose.

Current Release: v0.3

v0.3 DFOs are the prototypical On-Chain Organizations. As R&D protocols, they offer proof of concept that our ambitions are not only being realized, but with even greater promise than anticipated.

We have rigorously tested the security and functionality of all DFO features. In fact, even the DFO protocol is ruled by a DFO called DFOhub. Thanks to their flexible design, we’ve easily dealt with every bug and other issue, and we’ve always done so on-chain, deploying every line of code via voting. You can track every advancement (via on-chain data) here: dapp.dfohub.com > DFOhub > Governance > Proposals

Using DFOhub, we’ve deployed ethItem and Covenants. These three interoperable DFOs provide the scaffolding for the ethereans Operating System. And we have drawn up plans for the more sophisticated architecture of v0.5 to continue building our New Ethereum Order.

Upcoming Release: v0.5

DFOs are the evolution of DFOs. While the name might appear abstract, it really reflects a deeper level of sophistication for On-Chain Organizations programmability.

Cheaper Governance

The v0.5 DFO core is more secure and efficient, substantially reducing the cost of managing and voting for proposals. For a v0.3 DFO, creating a proposal costs ~4M gas; for an v0.5 DFO, it’s ~400K. That’s 90% cheaper.

ITEM-Based Treasuries

One of the fundamental concerns when building dApps on Ethereum is the tech undergirding tokens. In fact, most of the bugs in the ecosystem derive from incompatibilities caused by non-standard implementations of ERC20s, ERC721s and ERC1155s.

There are three ways to deal with this. Two of these are standard practice, but only mitigate the problem. Both involve centralized lists of tokens. These might improve efficiency, but always at the cost of unlisted tokens, and they can also severely limit the capabilities of the host protocol.

The DFO approach offers a genuine solution. Their treasuries hold native and wrapped Items, objects that are interoperable with all of Ethereum. When these treasuries interact with dApps, their Itemized liquidity flows with perfect compatibility, reducing 99% of possible bugs.

subDAOs

On-Chain Organizations are designed to replace off-chain owners of code. v0.5 DFOs achieve this, but can only be governed at a macro-level.

DFO governance is multilayered. They can implement subDAOs that use customized voting rules for governing fixed functionalities.

This allows their equity holders to replicate DAO governance in a secure on-chain environment, retaining exclusive ownership of the protocol and the ability to govern it at the macro-level.

Example 1:

An DFO implements a DFOhub-like deployer functionality, generation fee and all. Using a subDAO, holders of the DFO’s equity can govern the fee in isolation from the rest of the functionality’s code, and with preset rules that incentivizes good-faith and productive voting.

Example 2:

An DFO-based AMM can set up a subDAO for the governance of liquidity pool provider fees, customized so that LP token holders can vote on trading fee changes for their respective pools.

The v0.5 DFOhub frontend will help DFOs rule over fixed functions. They allow for combining poll-based administration with execution-based governance. DAOs on platforms like Aragon, Metacartel and DXdao could govern them via a v0.5 DFO’s subDAOs.

Surveyless subDAOs

The pace of on-chain governance presently lags behind the pace of DeFi. dApp governance cannot move fast enough to function securely or efficiently. Surveyless subDAOs offer a new, innovative solution, bypassing time consuming surveys with preset options that can be rapidly voted through; holders only need to reach the hard cap for one option for it to be implemented.

Example:

An DFO-based DEX sets up a surveyless subDAO for liquidity provider fees, with 6 possible options: 0.05%, 0.1%, 0.3%, 0.5%, 1% and 2%. Enough LP tokens are staked to reach the preset cap (based on fixed rules) for 0.1%. It is implemented the next block, without needs to wait for a Survey.

Multi-Token Governance

v0.5 DFO can set use multi-token governance to give different tokens different degrees of voting power. Holders can vote with all at once by using batch transfers.

v0.5 DFOs can also coordinate subDAOs (survey and surveyless) with multi-token governance to create dynamic voting systems that, for example, can curb whale tyranny with checks and balances, helping ensure the right kinds of decision making.

Example:

An DFO sets up rules to incentivize liquidity provision in AMMs, making it possible to vote with LP tokens with more voting powers than regular holders.

(Wrapped Items, which can contain any ERC20, ERC721 or ERC1155, and native Items can be used in DFO governance).

Example:

A game-based DFO can use different in-game Items as voting tokens with varying powers.

Minecraft: Factory-Centric Architecture

Like DFOs, DFOs can vote to execute single-purpose functions. However, they (and anyone else) can also deploy general-purpose factories. These are contracts that can be customized and cloned via executions of proposals to serve limitless purposes.

A factory can be set up so that anyone who uses it pays a fee to the owner. Credibility can be established by how often one is used. All will be stored in an easily accessible community chest, and will be just as easy to implement via voting.

Building a smart contract from scratch comes with risks. Battle-tested factories offer peace of mind, and you don’t need coding skills to use them.

Versioning

If a factory is upgraded, DFOs can use the new version or continue using an old one.

Improved Integrations

DFOs will be more easily integrated with ENS, EPNS and experimental eth tools (e.g. L2 solutions like Optimism and The Graph, if and when these are ready).

GitHub Replacement

Using on-chain data and IPFS, DFOs don’t need to rely on third parties like GitHub for anything. They will possess all of the tools required to clone, test, verify and discuss code. DFO-level surveys serve as the decentralized equivalent of GitHub pull requests. Governance is permissionless, with no special repo key holders.

Maintenance Mode

DFOs can vote to go into Maintenance Mode. While in this state, governance is restricted to fixed changes at the subDAO level, which can be helpful during late-stage beta development.

New Optional Standard Governance Rules

Voting power can be affected by length of blocks staked, for example, or by number of voters.

Small Improvements

Proxy design and state holder implementation will become cheaper.

Multi-AMM Secure DeFi Integrations

Now that Covenants has been released, all DFOs have access to multi-AMM contracts for swapping, liquidity crafting, farming, fixed inflation and more.

Tokenless Governance

For DFOs that require certain power structures, developers can set up tokenless governance to reach hard caps and vote ONLY at the DFO-level, with no power at the subDAO-level (via mint-vote-burn atomic transactions) without having to hold superfluous amounts of tokens.

This serves as an additional buffer against rug pulls and other security risks, and is especially helpful for devs like us who want to build and improve their dApps while gradually relieving control of them over time during early developments.

v0.3 to v0.5 Easy Switch

With the release of ethOS v0.5, v0.3 DFOs will be able to switch to v0.5 DFOs. We’ll add a simple token switch feature to facilitate this. DFOs don’t have to upgrade; but our own development will migrate to a new frontend for v0.5 and beyond.

The ethOS DFOs holders of $BUIDL, $UniFi, and $ARTE will automatically become DFOs holders during this transition via a token 1:1 switch.

v0.5 ethOS Experimental subDAOs For DFOhub, Item and Portal DFOs

Surveyless subDAO for fees

Token holders can govern isolated fees with surveyless subDAOs, securing DFOs earnings.

Surveyless subDAO for Inflation

Using these surveyless subDAOs, token holders will be able to rule part of each DFO’s Fixed Inflation structure and associated farming rules.

subDAO for ETH dividends

A percentage of each DFOs ETH treasury earnings will be distributed to holders via farming, effectively providing a way to farm ETH.

subDAO for Reserved Fixed Inflation

$BUIDL holders will be able to set up low-impact alternative fixed inflation systems for select tokens accrued in the DFOhub treasury via generation fees.

DFOhub Organization

DFOhub is a Decentralized Flexible Organization (DFO) that build the DFO technology. Thanks to the DFO standard, DFOhub is entirely independent from any off-chain entity. The $BUIDL voting token is a programmable equity of the DFOhub DFO; $BUIDL holders hold real equity of the protocol, and rule every part of its code and assets.

DFOhub earn by Generation Fee. By deploying a DFO, a 1.5% fee of the newly generated voting tokens is sent to the DFOhub Treasury wallet. By the DFO update the Generation fee will be flexible and managed via a subDAO.