[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-71300":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":17,"stars30d":17,"stars90d":16,"forks30d":16,"starsTrendScore":18,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":16,"starSnapshotCount":16,"syncStatus":28,"lastSyncTime":29,"discoverSource":30},71300,"DARC","Project-DARC\u002FDARC","Project-DARC","Decentralized Autonomous Regulated Company (DARC), a company virtual machine that runs on any EVM-compatible blockchain, with on-chain law system, multi-level tokens and dividends mechanism.","https:\u002F\u002Fdarc.app",null,"TypeScript",9172,6684,3062,1,0,3,9,41,"Other",false,"main",true,[],"2026-06-12 02:02:50","# Decentralized Autonomous Regulated Company (DARC)\n\nWelcome to the official repository for the Decentralized Autonomous Regulated Company (DARC) project. DARC is a project\nthat aims to create a decentralized autonomous company that is regulated by a plugin system based on commercial laws.\nThe project is currently in the early stages of development and is not yet ready for production use.\n\nEnglish | [简体中文](.\u002FREADME_cn.md) | [日本語](.\u002FREADME_ja.md)\n\n## Star History\n\n[![Star History Chart](https:\u002F\u002Fapi.star-history.com\u002Fsvg?repos=project-darc\u002Fdarc&type=Date)](https:\u002F\u002Fstar-history.com\u002F#project-darc\u002Fdarc&Date)\n\n\n## Join our community\n\nTelegram: [https:\u002F\u002Ft.me\u002Fprojectdarc](https:\u002F\u002Ft.me\u002Fprojectdarc)\nDiscord: [https:\u002F\u002Fdiscord.gg\u002FQzKbTHVgGG](https:\u002F\u002Fdiscord.gg\u002FQzKbTHVgGG)\n\n## Whitepaper\n\nEnglish: [darc-whitepaper.pdf](https:\u002F\u002Fgithub.com\u002FProject-DARC\u002FDARC-whitepaper\u002Fblob\u002Frelease\u002Fdarc-whitepaper.pdf)\n\nChinese(中文版): [darc-whitepaper-cn.pdf](https:\u002F\u002Fgithub.com\u002FProject-DARC\u002FDARC-whitepaper\u002Fblob\u002Frelease\u002Fdarc-whitepaper-cn.pdf)\n\n## What is DARC?\n\nDecentralized Autonomous Regulated Company (DARC) is a company virtual machine that can be compiled and deployed to\nEVM-compatible blockchains with following features:\n\n- **Multi-level tokens**, each level token can be used as common stock, preferred stock, convertible bonds, board of\n  directors, product tokens, non-fungible tokens (NFT), with different prices, voting power and dividend power, which\n  are defined by the company's plugin(law) system.\n- **Program** composed of a series of DARC instructions that include managing tokens, dividends, voting, legislation,\n  purchasing, withdrawing cash, and other company operations.\n- **Dividend Mechanism** for distributing dividends to token holders according to certain rules.\n- **Plugin-as-a-Law**.The plugin system serves as the by-law or commercial contract that supervises all operations. All\n  company operations need to be approved by the plugin system or corresponding voting process.\n\n## By-Law Script\n\nBy-law script is a JavaScript-like programming language that is used to define the company's commercial rules and\noperations on DARC. For example:\n\n```javascript\nmint_tokens(   \u002F\u002F mint token operation\n    [addr1, addr2, addr3],   \u002F\u002F token address\n    [0, 0, 0],   \u002F\u002F token class \n    [500, 300, 200]  \u002F\u002F number of tokens\n);\n\npay_cash(100000000, 0, 1); \u002F\u002F pay 0.1 ETH as purchase\n\ntransfer_tokens(   \u002F\u002F transfer token operation\n    [addr1, addr2, addr3],   \u002F\u002F token address\n    [0, 0, 0],   \u002F\u002F token class \n    [100, 100, 200]  \u002F\u002F number of tokens\n);\n\nadd_withdraw_cash(10000000);  \u002F\u002F add 0.01 ETH to withdraw balance\n\nwithdraw_cash_to(  \u002F\u002F withdraw cash from my account to other address\n    [addr4, addr5],       \u002F\u002F withdraw cash to addr4, addr5\n    [10000000, 10000000]  \u002F\u002F withdraw amount 0.01 ETH, 0.01 ETH\n);\n\n\n```\n\nAbove By-law Script will be transpiled via code generator and sent to corresponding DARC VM contract. The DARC will\nexecute the program if the plugin system approves. To add plugin and voting rules to the DARC, we can simple compose the\nplugin conditions and voting rules, then send them via operation `add_voting_rule()`, `add_and_enable_plugins()`\nor `add_plugins()`, and they will be deployed and effective immediately if the current plugin system approves the\noperation.\n\nHere is a quick example, assume we need to limit the transfer of tokens by major shareholders (>25%) by asking the board\nof directors for an all-hand vote (assuming 5 tokens in total), and it requires 100% approval (5 out of 5) in 1 hour. We\ncan add a new plugin and corresponding voting rule to the DARC VM contract:\n\n```javascript\nadd_voting_rule(  \u002F\u002F add a voting rule (as index 5)\n    [\n        {\n            voting_class: [1], \u002F\u002F voting token class: 1, level-1 token owners (board of directors) are required to vote\n            approve_percentage: 99,  \u002F\u002F 99% voting power is required to approve\n            voting_duration: 3600,  \u002F\u002F voting duration: 1 hour (3600 seconds)\n            execute_duration: 3600,  \u002F\u002F pending duration for execution: 1 hour (3600 seconds)\n            is_absolute_majority: true,  \u002F\u002F absolute majority is required, not relative majority\n        }\n    ]\n)\n\nadd_and_enable_plugins(   \u002F\u002F add and enable plugins (as index 7)\n    [\n        {\n            condition:  \u002F\u002F define the condition:\n                (operation == \"transfer_tokens\")   \u002F\u002F if operation is transfer_tokens\n                & (operator_total_voting_power_percentage > 25),  \u002F\u002F and addr1's voting power > 25%\n            return_type: voting_needed,  \u002F\u002F return type: requires a vote\n            return_level: 100,  \u002F\u002F priority: 100\n            votingRuleIndex: 5 \u002F\u002F voting rule index 5 (ask board of directors to vote and must 100% approve)\n            note: \"100% Approval is needed by board members to transfer tokens by major shareholders (>25%)\"\n            is_before_operation: false,  \u002F\u002F check the plugin after the operation is executed in sandbox\n        }\n    ]\n)\n```\n\nAfter above By-Law Script is executed, the DARC VM contract will add a new plugin and voting rule, and the plugin will\nbe effective immediately (if there exists any voting procedure related to `add_voting_rule()`\nand `add_and_enable_plugins()`, the plugin will be effective after the voting process is approved). If the\noperator (`addr1`) tries to transfer tokens to addr2, the plugin will check the condition and return `voting_needed` to\nthe DARC VM contract, and the DARC VM contract will ask the board of directors (level-1 token owners) to vote. If the\nboard of directors approves the operation, the operation will be executed in the sandbox, otherwise the operation will\nbe rejected. For example, if there are 3 voting rules are triggerd, the voting operation will be:\n\n```javascript\nvote([true, true, true])\n```\n\nIf the voting process is approved by the existing voting rules and plugins, the new program will be approved to execute\nin the next execution pending duration (1 hour in this example), and the program owner or any other members can execute\nthe program in the next 1 hour, or the program will be ignored and removed from the pending list.\n\n## \"Plugin-as-a-Law\"\n\nThe law of DARC is defined in below pseudo-code:\n\n```javascript\nif (plugin_condition == true) {\n    plugin_decision = allows \u002F denies \u002F requires a vote\n}\n```\n\nEach plugin contains a condition expression tree and a corresponding decision (return type). When the condition tree is\nevaluated to true while the program is submitted before running, the plugin will make a decision by allows, denies or\nrequires a vote. For example:\n\n### Example 1: Anti-Dilutive shares\n\nAnti-Dilutive shares is a basic mechanism to prevent the company (including DAO and other on-chain \"tokenomics\") from\nissuing too many shares and dilute the ownership of the existing shareholders. In DARC, the company and early-stage\ninvestors can define a law of \"anti-dilutive shares\", and the law can be abolished by certain process.\n\n***Law 1 (Anti-Dilutive Shares): Shareholder X should always holds 10% of the total stock.***\n\n*Design of Plugin: If operation is minting new level-0 tokens, plugin should check the state of token ownerships, X\nshould always keep a minimum total voting power of 10%, as well as dividend power of 10% after executing the operation*\n\nIn By-law script, we can define the plugin with following conditions:\n\n```javascript\n\u002F\u002F define X's address\nconst x_addr = \"0x1234567890123456789012345678901234567890\";\n\n\u002F\u002F define the plugin\nconst anti_delutive = {\n\n    \u002F\u002F define the trigger condition\n    condition:\n        ((operation == \"mint_tokens\")             \u002F\u002F if operator is minting new tokens\n            | (operation == \"pay_to_mint_tokens\"))   \u002F\u002F or operator is paying to mint new tokens\n        &                                          \u002F\u002F and        \n        ((total_voting_power_percentage(x) \u003C 10)    \u002F\u002F X's total voting power \u003C 10%\n            | (total_dividend_power_percentage(x) \u003C 10)),   \u002F\u002F or X's total dividend power \u003C 10%\n\n    \u002F\u002F define the decision: reject the operation\n    return_type: NO,\n\n    \u002F\u002F define the priority: 100\n    return_level: 100,\n\n    \u002F\u002F check the plugin after the operation is executed in sandbox\n    is_before_operation: false,\n}\n```\n\nSince it checks the state of token ownerships, the plugin should be executed after the operation is executed inside the\nDARC's sandbox. If the plugin's condition is evaluated to true, the plugin will deny the operation after executing in\nthe sandbox, and the operation will be rejected to be executed in the real environment. Otherwise, \"minting new tokens\"\nwill be allowed to execute.\n\nWhen this plugin is added to the DARC, the operator (the author of current program) must mint extra tokens to\naddress `x_addr` to satisfy the **Law 1** above, otherwise it will be rejected. For example, the DARC has only one level\nof tokens (level 0, voting power = 1, dividend power = 1), the stock ownerships are:\n\n| ShareHolders | Number of tokens | Percentage |\n|--------------|------------------|------------|\n| CEO          | 400              | 40%        |\n| CTO          | 300              | 30%        |\n| CFO          | 200              | 20%        |\n| VC X         | 100              | 10%        |\n| **Total**    | **1000**         | **100%**   |\n\nIf the operator want to mint 200 tokens and issue them to VC Y, the operator must mint 20 tokens to address `x_addr` to\nsatisfy the **Law 1** above, otherwise the operation will be rejected. Here is a sample investment program by VC Y:\n\n```javascript\npay_cash(1000000000000)  \u002F\u002F pay 1000 ETH to the DARC\nmint_tokens(20, 0, x_addr)  \u002F\u002F mint 20 level-0 tokens to address x_addr\nmint_tokens(180, 0, y_addr)  \u002F\u002F mint 180 level-0 tokens to address y_addr\nadd_and_enable_plugin([new_law_1, new_law_2, new_law_3])  \u002F\u002F investment laws by VC Y\n```\n\nAfter the operation, the stock ownerships are:\n\n| ShareHolders | Number of tokens | Percentage |\n|--------------|------------------|------------|\n| CEO          | 400              | 33.33%     |\n| CTO          | 300              | 25%        |\n| CFO          | 200              | 16.67%     |\n| VC X         | 120              | 10%        |\n| VC Y         | 180              | 15%        |\n| **Total**    | **1200**         | 100%       |\n\nAlso another plugin should be added to the DARC to define the legislation of the \"Abolish Law 1\":\n\n***Law 1.1(Law 1 Appendix): Both Law 1 and Law 1 Appendix (current Law) can be abolished if and only if the operator is\nX***\n\n*Design of Plugin: If operation is \"disable_plugins\", and the plugin that to be disabled is with `id == 1` or `id == 2`,\nand the operator is not X, then the plugin should reject the operation (assume the anti dilutive law index is 1, and the\nappendix law index is 2, both are before-operation plugins)*\n\n```javascript\nconst law_1_appendix = {\n\n    \u002F\u002F define the trigger condition\n    condition:\n        (operation == \"disable_plugins\")\n        & ((disable_after_op_plugin_id == 1) | (disable_after_op_plugin_id == 2))\n        & (operator != x_addr),\n\n    \u002F\u002F define the decision\n    return_type: no,\n\n    \u002F\u002F define the priority\n    return_level: 100,\n\n    \u002F\u002F reject the operation before sandbox\n    is_before_operation: true,\n}\n```\n\n### Example 2: Bet-on Agreement\u002FValuation-Adjustment Mechanism(VAM) Agreement\n\n***Law2: If total revenue \u003C 1000 ETH by 2035\u002F01\u002F01, shareholder X can take over 75% of total voting power and 90% of\ndividend power.***\n\n*Design of Plugin: After executing in sandbox, check the following conditions:*\n\n- *timestamp >= 2035\u002F01\u002F01*\n\n- *revenue since 2000\u002F01\u002F01 \u003C 1000 ETH*\n\n- *operation is \"mint_tokens\"*\n\n- *total voting power of x \u003C= 75%*\n\n- *the dividend power of x \u003C= 90%*\n\n*then the plugin should approve the operation*\n\nIn By-law script, we can define the above plugin as following:\n\n```javascript\nconst bet_on_2 = {\n\n    \u002F\u002F define the trigger condition\n    condition:\n        (timestamp >= toTimestamp('2035\u002F01\u002F01')) &\n        (revenue_since(946706400) \u003C 1000000000000) & \u002F\u002F 1000000000000 Gwei = 1000 ETH\n        (operation == \"mint_tokens\") &\n        (total_voting_power_percentage(x) \u003C 75) &\n        (total_dividend_power_percentage(x) \u003C 90),\n\n    \u002F\u002F define the decision\n    return_type: yes,\n\n    \u002F\u002F define the priority\n    return_level: 100,\n\n    \u002F\u002F approve the operation after executing in sandbox\n    is_before_operation: false,\n}\n```\n\n### Example 3: Employee Payroll\n\n***Law 3: The payroll for employees with role level X should be 10 ETH per month.***\n\n*Design of Plugin: If operation is \"add withdrawable cash\", the amount is less than or equals to 10 ETH, and the last\noperation was at least 30 days, then this operation should be approved and skip sandbox check*\n\nIn By-law script, we can define the plugin with following conditions (for example, level X = 2 can withdraw 10 ETH per\n30 days):\n\n```javascript\nconst payroll_law_level_2 = {\n    condition:\n        (operation == \"add_withdrawable_cash\") &   \u002F\u002F operation is \"add withdrawable cash\"\n        (member_role_level == 2) &   \u002F\u002F the operator address is in role level 2\n\n        \u002F\u002F add cash by \u003C every 30 days = 2592000 seconds\n        (operator_last_operation_window(\"add_withdrawable_cash\") >= 2592000) &\n        \u002F\u002F each time add \u003C 10000000000 Gwei = 10 ETH to the account\n        (add_withdrawable_cash_amount \u003C= 10000000000),\n\n    \u002F\u002F approve the operation and skip sandbox check\n    return_type: yes_and_skip_sandbox,\n    return_level: 1\n    is_before_operation: true,\n}\n```\n\nWith the plugin above, the operator can add withdrawable cash to the employee's account with amount less than or equals\nto 10 ETH, and the last operation was at least 30 days. The plugin will approve the operation and skip the sandbox\ncheck. When the employee address is disable, removed from role level X, or other plugins with higher priority deny the\noperation, these operations will be rejected.\n\n### Example 4: Voting and legislation\n\nFor daily operations, the board of directors can be defined as a group of addresses, and the voting mechanism can be\nused to make decisions. For example, let's design the voting mechanism for the following scenario:\n\n1. Any address X with more than 10% total voting power can be added to the board by minting 1 token (level 2, board\n   voting token), if and only if the behavior is approved by 2\u002F3 of all the board members (voting rule 1).\n\n```javascript\nconst add_board_member = {\n    condition:\n        (operation == \"mint_tokens\") &   \u002F\u002F operation is \"mint_tokens\"\n        (mint_tokens_level == 2) &  \u002F\u002F the token level is 2\n        (mint_tokens_amount == 1) &  \u002F\u002F the amount is 1\n        (operator_total_voting_power_percentage >= 10),   \u002F\u002F the operator address holds at least 10% of the total voting power\n    return_type: voting_needed,\n    voting_rule: 1,  \u002F\u002F Under the voting rule 1, the operation will be approved if and only if 2\u002F3 of all the board members approve the operation\n    return_level: 100,\n    is_before_operation: false, \u002F\u002F make the decision after executing in sandbox\n}\n```\n\n2. Any operator with more than 7% of all voting power can submit `enable_plugins()` , and it needs to be approved by\n   100% of all the board members. Each operator can try to activate plugin per 10 days.\n\n```javascript\nconst enable_plugin = {\n    condition:\n        (operation == \"enable_plugins\") &   \u002F\u002F operation is \"enable_plugins\"\n        (operator_total_voting_power_percentage >= 7) &   \u002F\u002F the operator address holds at least 7% of the total voting power\n        (operator_last_operation_window(\"enable_plugin\") >= 864000),  \u002F\u002F each operator can try to enable plugins once per 864000 seconds (10 days)\n\n    return_type: voting_needed,\n    voting_rule: 2,  \u002F\u002F Under the voting rule 2, the operation will be approved if and only if 100% of all the board members approve the operation\n    return_level: 100,\n    is_before_operation: false, \u002F\u002F make the decision after executing in sandbox\n}\n```\n\n3. To disable plugins 2,3 and 4, the operator needs to hold at least 20% of total voting power, and the operation needs\n   to be approved by 70% of all common stock token(level-0) voters as relative majority(voting rule 2). For each member\n   of DARC, this operation can be executed once per 15 days (1296000 seconds).\n\n```javascript\nconst disable_2_3_4 = {\n    condition:\n        (operation == \"disable_plugins\") &   \u002F\u002F operation is \"disable_plugins\"\n        (\n            disable_after_op_plugin_id == 2\n            | disable_after_op_plugin_id == 3\n            | disable_after_op_plugin_id == 4\n        ) &  \u002F\u002F disable after operation plugins 2,3 and 4\n        (operator_total_voting_power_percentage >= 20) &   \u002F\u002F the operator address holds at least 20% of the total voting power\n        (operator_last_operation_window(\"disable_plugins\") >= 1296000),  \u002F\u002F each operator can try to disable plugins once per 1296000 seconds (15 days)\n    return_type: voting_needed,\n    voting_rule: 3,  \u002F\u002F Under the voting rule 3, the operation will be approved if and only if 70% of all the common stock holders approve the operation\n    is_before_operation: false, \u002F\u002F make the decision after sandbox check\n}\n```\n\n### Example 5: Multi-level Tokens: Product tokens and Non-fungible tokens\n\nHere is an example of how to design a token with different levels of voting power and dividend power. The voting power\nand dividend power are used to calculate the voting power and dividend power of each token holder. Here is the table of\nthe token levels:\n\n| Level | Token                            | Voting Power | Dividend Power | Total Supply |\n|-------|----------------------------------|--------------|----------------|--------------|\n| 0     | Level-0 Common Stock             | 1            | 1              | 100,000      |\n| 1     | Level-1 Stock                    | 20           | 1              | 10,000       |\n| 2     | Board of Directors               | 1            | 0              | 5            |\n| 3     | Executives                       | 1            | 0              | 5            |\n| 4     | Non-Voting Shares                | 0            | 1              | 200,000      |\n| 5     | Product Token A (0.01 ETH\u002Ftoken) | 0            | 0              | ∞            |\n| 6     | Product Token B (10 ETH\u002Ftoken)   | 0            | 0              | ∞            |\n| 7     | Non-Fungible Token #1            | 0            | 0              | 1            |\n| 8     | Non-Fungible Token #2            | 0            | 0              | 1            |\n| 9     | Non-Fungible Token #3            | 0            | 0              | 1            |\n| 10    | Non-Fungible Token #4            | 0            | 0              | 1            |\n| 11    | Non-Fungible Token #5            | 0            | 0              | 1            |\n| ...   | ...                              | ...          | ...            | ...          |\n\nTo pay for service or prochase for products, customers can use `pay_cash()` to pay for the service directly, or\nuse `pay_to_mint_tokens()` as a payment method and receive product tokens\u002FNFTs.\n\nHere is an example about how to define \"Product Token A\" and \"NFT\" price and total supply.\n\n```javascript\nconst product_token_A_price_law = {\n    condition:\n        (operation == \"pay_to_mint_tokens\") &   \u002F\u002F operation is \"pay_to_mint_tokens\"\n        (pay_to_mint_tokens_level == 5) &  \u002F\u002F the token level is 5\n        (pay_to_mint_price_per_token >= 10000000000000000),   \u002F\u002F price per token >= 0.01 ETH = 10000000000000000 wei\n\n    return_type: yes_and_skip_sandbox,  \u002F\u002F approve the operation and skip sandbox check\n    return_level: 1,\n    is_before_operation: true, \u002F\u002F approve the operation and skip sandbox check\n}\n\nconst NFT_price_law = {\n    condition:\n        (operation == \"pay_to_mint_tokens\") &   \u002F\u002F operation is \"pay_to_mint_tokens\"\n        (pay_to_mint_tokens_level >= 7) &  \u002F\u002F the token level is 7 or higher\n        (pay_to_mint_token_amount == 1) &  \u002F\u002F only allow to mint 1 token at a time\n        (pay_to_mint_current_level_total_supply == 0) &  \u002F\u002F current total supply is 0\n        (pay_to_mint_price_per_token >= 10000000000000000000),   \u002F\u002F price per token >= 10 ETH = 10000000000000000000 wei\n\n    return_type: yes_and_skip_sandbox,  \u002F\u002F approve the operation and skip sandbox check\n    return_level: 1,\n    is_before_operation: true, \u002F\u002F approve the operation and skip sandbox check\n}\n```\n\n### Example 6: Lock dividend yield rate for 5 years\n\nThe dividend mechanism is designed to distribute dividends to token holders under certain rules:\n\n1. For each `X` purchase transactions, take Y‱ of the total income as the dividendable cash\n2. The `offer_dividend()` operation can be called, which will distribute the dividendable cash to token holders'\n   dividend withdraw balance\n3. The amount of dividends per token holder (X) is calculated by the following\n   formula: `dividend_X = dividendable_cash * dividend_power(X) \u002F total_dividend_power`\n4. After the `offer_dividend()` operation is called, the dividendable cash and dividendable transaction counter will be\n   set to 0, and the dividend withdraw balance of each token holder will be increased by `dividend_X`\n\nTo make sure the dividend yield rate is stable, we can add a plugin to the DARC to lock the dividend yield rate for 5\nyears by limiting the `set_parameters()` function.\n\n***Law 6: The dividend yield rate should be locked > 500‱ (5%) before 2030-01-01.***\n\n```javascript\nconst dividend_yield_rate_law = {\n    condition:\n        (operation == \"set_parameters\") &  \u002F\u002F operation is \"set_parameters\"\n        (set_parameters_key == \"dividendPermyriadPerTransaction\") &  \u002F\u002F the key is \"dividend_yield_rate\"\n        (set_parameters_value \u003C 500) &  \u002F\u002F the value is \u003C 500‱ (5%)\n        (timestamp \u003C 1893477600),  \u002F\u002F the timestamp \u003C unix timestamp  2030-01-01 00:00:00 (UTC) \n\n    return_type: no,  \u002F\u002F reject the operation\n    return_level: 1,\n    is_before_operation: true, \u002F\u002F reject the operation and skip sandbox check\n}\n```\n\n### Example 7: Investment program package\n\nHere is an unofficial example program of **Simple agreement for future equity (SAFE)**, a common investment contract by\na VC firm:\n\n1. The VC firm will pay 1000 ETH (1000000000000 Gwei) cash to the DARC as investment\n2. The VC firm will be granted 100,000,000 level-0 tokens (common stock) and 1 level-2 token (board of members)\n3. The VC firm will be granted the right to disable plugins 5, 6, 7\n4. The VC firm will be granted the right to enable plugins 8, 9, 10, 11\n5. The VC firm will be granted the right to change its role to level-5 (majority shareholder level)\n6. It's recommended to sign and scan a PDF document to record the agreement, upload the PDF document to IPFS, and add\n   the IPFS hash `QmcpxHN3a5HYnPurtuDs3jDfDSg1LPDe2KVBUG4RifcSbC` to the DARC permanent storage array. This can help the\n   emergency agent to verify and fix DARC technical issues if needed.\n\n```javascript\nconst vc_addr = \"0x1234567890123456789012345678901234567890\";  \u002F\u002F define my address\n\npay_cash(1000000000000, 0, 1);  \u002F\u002F pay 1000 ETH = 1000000000000 Gwei cash\n\nmint_token([vc_addr], [100000000], [0]);  \u002F\u002F mint 100,000,000 level-0 tokens (common stock) to VC firm\n\nmint_token([vc_addr], [1], [2]);  \u002F\u002F mint a single 2-level token (board of members) to VC firm\n\ndisable_plugins([5, 6, 7], [false, false, false]) \u002F\u002F disable previes after-operation plugins 5, 6, 7\n\nenable_plugins([8, 9, 10, 11], [false, false, false, false]) \u002F\u002F enable new added plugins 8, 9, 10, which were added before this program\n\nchange_member_role(vc_addr, 5);  \u002F\u002F change the role of VC firm to level-5 (majority shareholder level)\n\n\u002F** Finally, sign and scan a SAFE document,\n * upload and pin on IPFS, and add the IPFS hash value to the DARC\n * just in case if DARC needs emergency agent to take over the DARC\n *\u002F\nadd_storage(['QmcpxHN3a5HYnPurtuDs3jDfDSg1LPDe2KVBUG4RifcSbC']);\n```\n\n## Building the source\n\nSince Hardhat and OpenZeppelin are used, the project can be built using the following commands:\n\n1. Install dependencies\n\n   We recommend that you use `pnpm` instead of `npm`, but `npm` can also work.\n\n   `pnpm` is a newer package manager that has some advantages over npm. It is faster, more efficient, and disk-space\n   friendly.\n\n    ```shell\n    cd darc-protocol\n    npm install\n    ```\n\n2. Compile the contracts\n\n    ```shell\n    npx hardhat compile\n    ```\n\n3. Run the Darc test network\n\n    ```shell\n    npm run node\n    ```\n\n4. Test contracts\n\n    ```shell\n    npx hardhat test\n    REPORT_GAS=true npm run test\n    ```\n\n5. Deploy contracts\n\n    ```shell\n    npm run deploy\n    ```\n","Decentralized Autonomous Regulated Company (DARC) 是一个基于EVM兼容区块链运行的公司虚拟机，内置链上法律系统、多层级代币和分红机制。其核心技术特点包括多层次代币体系，支持普通股、优先股、可转债等多种形式，并通过插件（法律）系统定义价格、投票权和分红权；以及由一系列DARC指令组成的程序，涵盖管理代币、分红、投票等公司运营活动。此外，DARC还引入了“插件即法律”的概念，所有操作需经插件系统或相应投票过程批准。该项目适用于希望在去中心化环境中构建受监管且灵活的企业结构的场景，目前处于开发初期阶段。",2,"2026-06-11 03:37:02","high_star"]