Decentralized Autonomous Regulated Company (DARC)

Welcome to the official repository for the Decentralized Autonomous Regulated Company (DARC) project. DARC is a project that aims to create a decentralized autonomous company that is regulated by a plugin system based on commercial laws. The project is currently in the early stages of development and is not yet ready for production use.

English | 简体中文 | 日本語

Star History

Join our community

Telegram: https://t.me/projectdarc Discord: https://discord.gg/QzKbTHVgGG

Whitepaper

English: darc-whitepaper.pdf

Chinese(中文版): darc-whitepaper-cn.pdf

What is DARC?

Decentralized Autonomous Regulated Company (DARC) is a company virtual machine that can be compiled and deployed to EVM-compatible blockchains with following features:

• Multi-level tokens, each level token can be used as common stock, preferred stock, convertible bonds, board of directors, product tokens, non-fungible tokens (NFT), with different prices, voting power and dividend power, which are defined by the company's plugin(law) system.
• Program composed of a series of DARC instructions that include managing tokens, dividends, voting, legislation, purchasing, withdrawing cash, and other company operations.
• Dividend Mechanism for distributing dividends to token holders according to certain rules.
• Plugin-as-a-Law.The plugin system serves as the by-law or commercial contract that supervises all operations. All company operations need to be approved by the plugin system or corresponding voting process.

By-Law Script

By-law script is a JavaScript-like programming language that is used to define the company's commercial rules and operations on DARC. For example:

mint_tokens(   // mint token operation
    [addr1, addr2, addr3],   // token address
    [0, 0, 0],   // token class 
    [500, 300, 200]  // number of tokens
);

pay_cash(100000000, 0, 1); // pay 0.1 ETH as purchase

transfer_tokens(   // transfer token operation
    [addr1, addr2, addr3],   // token address
    [0, 0, 0],   // token class 
    [100, 100, 200]  // number of tokens
);

add_withdraw_cash(10000000);  // add 0.01 ETH to withdraw balance

withdraw_cash_to(  // withdraw cash from my account to other address
    [addr4, addr5],       // withdraw cash to addr4, addr5
    [10000000, 10000000]  // withdraw amount 0.01 ETH, 0.01 ETH
);

Above By-law Script will be transpiled via code generator and sent to corresponding DARC VM contract. The DARC will execute the program if the plugin system approves. To add plugin and voting rules to the DARC, we can simple compose the plugin conditions and voting rules, then send them via operation add_voting_rule(), add_and_enable_plugins() or add_plugins(), and they will be deployed and effective immediately if the current plugin system approves the operation.

Here is a quick example, assume we need to limit the transfer of tokens by major shareholders (>25%) by asking the board of directors for an all-hand vote (assuming 5 tokens in total), and it requires 100% approval (5 out of 5) in 1 hour. We can add a new plugin and corresponding voting rule to the DARC VM contract:

add_voting_rule(  // add a voting rule (as index 5)
    [
        {
            voting_class: [1], // voting token class: 1, level-1 token owners (board of directors) are required to vote
            approve_percentage: 99,  // 99% voting power is required to approve
            voting_duration: 3600,  // voting duration: 1 hour (3600 seconds)
            execute_duration: 3600,  // pending duration for execution: 1 hour (3600 seconds)
            is_absolute_majority: true,  // absolute majority is required, not relative majority
        }
    ]
)

add_and_enable_plugins(   // add and enable plugins (as index 7)
    [
        {
            condition:  // define the condition:
                (operation == "transfer_tokens")   // if operation is transfer_tokens
                & (operator_total_voting_power_percentage > 25),  // and addr1's voting power > 25%
            return_type: voting_needed,  // return type: requires a vote
            return_level: 100,  // priority: 100
            votingRuleIndex: 5 // voting rule index 5 (ask board of directors to vote and must 100% approve)
            note: "100% Approval is needed by board members to transfer tokens by major shareholders (>25%)"
            is_before_operation: false,  // check the plugin after the operation is executed in sandbox
        }
    ]
)

After above By-Law Script is executed, the DARC VM contract will add a new plugin and voting rule, and the plugin will be effective immediately (if there exists any voting procedure related to add_voting_rule() and add_and_enable_plugins(), the plugin will be effective after the voting process is approved). If the operator (addr1) tries to transfer tokens to addr2, the plugin will check the condition and return voting_needed to the DARC VM contract, and the DARC VM contract will ask the board of directors (level-1 token owners) to vote. If the board of directors approves the operation, the operation will be executed in the sandbox, otherwise the operation will be rejected. For example, if there are 3 voting rules are triggerd, the voting operation will be:

vote([true, true, true])

If the voting process is approved by the existing voting rules and plugins, the new program will be approved to execute in the next execution pending duration (1 hour in this example), and the program owner or any other members can execute the program in the next 1 hour, or the program will be ignored and removed from the pending list.

"Plugin-as-a-Law"

The law of DARC is defined in below pseudo-code:

if (plugin_condition == true) {
    plugin_decision = allows / denies / requires a vote
}

Each plugin contains a condition expression tree and a corresponding decision (return type). When the condition tree is evaluated to true while the program is submitted before running, the plugin will make a decision by allows, denies or requires a vote. For example:

Example 1: Anti-Dilutive shares

Anti-Dilutive shares is a basic mechanism to prevent the company (including DAO and other on-chain "tokenomics") from issuing too many shares and dilute the ownership of the existing shareholders. In DARC, the company and early-stage investors can define a law of "anti-dilutive shares", and the law can be abolished by certain process.

Law 1 (Anti-Dilutive Shares): Shareholder X should always holds 10% of the total stock.

Design of Plugin: If operation is minting new level-0 tokens, plugin should check the state of token ownerships, X should always keep a minimum total voting power of 10%, as well as dividend power of 10% after executing the operation

In By-law script, we can define the plugin with following conditions:

// define X's address
const x_addr = "0x1234567890123456789012345678901234567890";

// define the plugin
const anti_delutive = {

    // define the trigger condition
    condition:
        ((operation == "mint_tokens")             // if operator is minting new tokens
            | (operation == "pay_to_mint_tokens"))   // or operator is paying to mint new tokens
        &                                          // and        
        ((total_voting_power_percentage(x) < 10)    // X's total voting power < 10%
            | (total_dividend_power_percentage(x) < 10)),   // or X's total dividend power < 10%

    // define the decision: reject the operation
    return_type: NO,

    // define the priority: 100
    return_level: 100,

    // check the plugin after the operation is executed in sandbox
    is_before_operation: false,
}

Since it checks the state of token ownerships, the plugin should be executed after the operation is executed inside the DARC's sandbox. If the plugin's condition is evaluated to true, the plugin will deny the operation after executing in the sandbox, and the operation will be rejected to be executed in the real environment. Otherwise, "minting new tokens" will be allowed to execute.

When this plugin is added to the DARC, the operator (the author of current program) must mint extra tokens to address x_addr to satisfy the Law 1 above, otherwise it will be rejected. For example, the DARC has only one level of tokens (level 0, voting power = 1, dividend power = 1), the stock ownerships are:

| ShareHolders | Number of tokens | Percentage | |--------------|------------------|------------| | CEO | 400 | 40% | | CTO | 300 | 30% | | CFO | 200 | 20% | | VC X | 100 | 10% | | Total | 1000 | 100% |

If the operator want to mint 200 tokens and issue them to VC Y, the operator must mint 20 tokens to address x_addr to satisfy the Law 1 above, otherwise the operation will be rejected. Here is a sample investment program by VC Y:

pay_cash(1000000000000)  // pay 1000 ETH to the DARC
mint_tokens(20, 0, x_addr)  // mint 20 level-0 tokens to address x_addr
mint_tokens(180, 0, y_addr)  // mint 180 level-0 tokens to address y_addr
add_and_enable_plugin([new_law_1, new_law_2, new_law_3])  // investment laws by VC Y

After the operation, the stock ownerships are:

| ShareHolders | Number of tokens | Percentage | |--------------|------------------|------------| | CEO | 400 | 33.33%