Decentralized Autonomous Regulated Company (DARC) Framework Documentation

This repository houses the core components for the Decentralized Autonomous Regulated Company (DARC) initiative. DARC establishes a novel paradigm for decentralized autonomous entities, enforcing operational conduct via a modular system designed to mirror commercial statutes and regulatory frameworks.

Status: The project is currently in its foundational development phase and should not be utilized for live production environments.

English | 简体中文

Connect With Us

Engage with the community via Telegram: https://t.me/projectdarc

Conceptual Overview of DARC

The Decentralized Autonomous Regulated Company (DARC) functions as a dedicated virtual machine environment, deployable across any EVM-compliant blockchain. Key functionalities include:

• Hierarchical Tokenization: Support for diverse asset classes—encompassing common equity, preferred stock, convertible debt instruments, board memberships, product units, and non-fungible assets (NFTs). The inherent value metrics (e.g., pricing, suffrage weight, profit entitlement) for each class are dynamically dictated by the organization's installed regulatory modules (the 'law' system).
• Instructional Programs: Execution logic is defined by a sequence of DARC Virtual Machine instructions, governing actions such as asset issuance, earnings allocation, shareholder voting, by-law modification, procurement, and cash repatriation.
• Profit Allocation Engine: A robust mechanism for distributing accrued revenue streams to registered asset holders based on predefined entitlements.
• Regulation via Plugins (Statutory Control): The plugin architecture serves as the governing body of commercial bylaws and contractual agreements. Every proposed corporate maneuver must receive validation from this supervisory plugin layer, often contingent upon a successful governance vote.

Statutory Scripting Language

The governance framework is codified using a JavaScript-adjacent scripting dialect, intended for defining operational mandates and commercial stipulations within the DARC environment. Illustration of core operations:

javascript mint_asset( // Function for asset creation [recipient_addr1, recipient_addr2, recipient_addr3], // Target addresses [asset_type_id_a, asset_type_id_b, asset_type_id_c], // Token classification indices [quantity_a, quantity_b, quantity_c] // Volume to generate );

process_expenditure(100000000, 0, 1); // Allocate 0.1 ETH equivalent for acquisition purposes

transfer_entitlements( // Operation to shift ownership rights [owner_addr1, owner_addr2, owner_addr3], // Current asset holders [asset_type_id_a, asset_type_id_b, asset_type_id_c], // Asset classification [transfer_volume_1, transfer_volume_2, transfer_volume_3] // Quantities being moved );

adjust_disbursement_pool(10000000); // Increment the balance eligible for owner withdrawal by 0.01 ETH equivalent

execute_payout_to( // Initiate withdrawal of funds to specified accounts [beneficiary_addr4, beneficiary_addr5], // Payee addresses [payout_amount_1, payout_amount_2], // Corresponding fund amounts (0.01 ETH, 0.01 ETH) { source_account: 'treasury' } );

This Statutory Script is subsequently processed by a code generator, resulting in byte-code executable by the target DARC VM instance. Execution proceeds only upon validation by the active regulatory plugins. To integrate new bylaws or voting prerequisites, commands such as introduce_governance_rule(), install_and_activate_plugins(), or install_plugins() are utilized. These definitions are immediately integrated and take effect, assuming any associated meta-governance procedures (e.g., rule amendments) are ratified.

Consider a scenario requiring supermajority board approval (100% consensus among directors) over a one-hour window for any asset transfer initiated by an entity holding over 25% of total voting influence (assuming 5 total voting units):

javascript introduce_governance_rule( // Define governance requirement set (e.g., index 5) [ { voting_class_ref: [1], // Voting token class reference: 1, designates level-1 token custodians (Board) as required voters quorum_threshold: 99, // 99% of designated voting power must assent resolution_period_seconds: 3600, // Mandate duration: 1 hour execution_delay_seconds: 3600, // Confirmation window before execution: 1 hour require_absolute_majority: true, // Enforce absolute majority rule set } ] )

install_and_activate_plugins( // Integrate and empower plugins (e.g., index 7) [ { trigger_condition: // Logic defining when this rule applies: (action_type == "transfer_entitlements") // If the action is an asset transfer & (initiator_total_voting_power_percentage > 25), // AND the originator commands > 25% of voting weight decision_output: vote_mandated, // Result: Requires a formal vote priority_level: 100, governance_rule_index: 5 // Reference governance rule 5 (Board vote, 100% approval required) notes: "Transfer by majority shareholder (>25%) necessitates full Board ratification (100%)" execution_timing: post_simulation, // Plugin evaluation occurs after tentative execution in the sandbox } ] )

Upon successful execution of the above Statutory Script, the DARC VM incorporates the new governance mandate and regulatory plugin. The plugin becomes active immediately (unless its activation itself is subject to a voting protocol, in which case it waits for approval). If a major shareholder attempts an asset transfer, the plugin intercepts the request, triggers the specified vote among level-1 token holders, and proceeds with execution only if ratified. A successful vote initiates a one-hour pending period before the transfer is finally committed.

If multiple governance procedures are triggered simultaneously, the final verdict is synthesized via:

javascript cast_vote([vote_result_1, vote_result_2, vote_result_3])

If all active mandates are satisfied, the program payload enters the execution queue for the defined confirmation window (1 hour here). Any interested party may submit the finalized program during this window, or the proposal will be discarded.

The Regulatory Plugin Paradigm

The core law of DARC adheres to the following pseudo-code structure:

javascript if (plugin_condition_met == true) { plugin_determination = permit / veto / mandate_vote }

Each regulatory plugin comprises a logical expression tree and an associated mandated outcome. If the expression evaluates to true when the program is submitted for processing, the plugin issues its decision (permit, veto, or require a vote).

Case Study 1: Shareholder Dilution Prevention

Statute: Shareholder X must perpetually maintain a minimum 10% stake in total issued equity.

Plugin Design: If the operation involves the creation of new level-0 assets, the plugin inspects current ownership distributions. If executing the mint operation would reduce X's collective voting influence or profit entitlement below the 10% floor, the operation is vetoed.

javascript // Define X's constant address identifier const address_x = "0x1234567890123456789012345678901234567890";

// Define the protective plugin const anti_dilution_statute = {

// Trigger condition set
trigger_condition:
    ((action_type == "mint_asset")             // If new assets are being issued
        | (action_type == "issue_for_purchase"))   // or assets are issued against payment
    &                                          // AND        
    ((combined_voting_weight(address_x) < 10)    // X's total voting claim drops below 10%
        | (combined_dividend_claim(address_x) < 10)),   // or X's total dividend claim drops below 10%,

// Decision: Reject the transaction
decision_output: VETO,

// Priority setting
priority_level: 100,

// Check after simulation
execution_timing: post_simulation,

}

Because this check relies on post-operation state evaluation, it executes within the DARC sandbox simulation. If the conditions are met post-simulation, the transaction is aborted in the live environment. If the plugin is integrated, the program proposing the minting must first inject enough new assets to address address_x to satisfy Statute 1, or the operation will fail.

Example Initial State:

Holder	Count	% Equity	Voting/Dividend Power (Level 0 = 1:1)
CEO	400	40%	40%
CTO	300	30%	30%
CFO	200	20%	20%
VC X	100	10%	10%
Total	1000	100%	100%

If an operator attempts to issue 200 new level-0 assets to VC Y, they must concurrently issue 20 tokens to address_x to maintain X's 10% floor, otherwise the anti-dilution plugin rejects the batch operation. A compliant investment sequence involving VC Y:

javascript process_expenditure(1000000000000) // Invest 1000 ETH equivalent mint_asset([address_x], [0], 20) // Shore up VC X's stake (20 level-0 tokens) mint_asset([address_y], [0], 180) // Issue remaining 180 tokens to VC Y install_and_activate_plugins([new_statute_1, new_statute_2, new_statute_3]) // Introduce VC Y's investment mandates

Post-Operation State:

Holder	Count	% Equity	Voting/Dividend Power
CEO	400	33.33%	33.33%
CTO	300	25%	25%
CFO	200	16.67%	16.67%
VC X	120	10%	10%
VC Y	180	15%	15%
Total	1200	100%	100%

Furthermore, a complementary plugin must govern the repeal of Statute 1:

Statute 1.1 (Appendix to Statute 1): Statutes 1 and 1.1 may only be decommissioned if the initiating party is X.

Plugin Design: If the operation is 'disable_plugins', targets plugin IDs 1 or 2, and the initiator is not X, the plugin issues a veto (assuming statute indices 1 and 2 are pre-operation plugins).

javascript const statute_1_appendix = {

// Trigger condition definition
trigger_condition:
    (action_type == "disable_plugins")
    & ((target_plugin_id == 1) | (target_plugin_id == 2))
    & (initiator_address != address_x),

// Decision
decision_output: VETO,

// Priority
priority_level: 100,

// Reject before simulation commences
execution_timing: pre_simulation,

}

Case Study 2: Valuation Adjustment Mechanism (VAM) Clause

Statute 2: Should cumulative revenue remain below 1000 ETH by the epoch 2035/01/01, Shareholder X gains irrevocable control over 75% of total voting rights and 90% of profit entitlements.

Plugin Design: Post-simulation check for:

• Current epoch >= 2035/01/01
• Accumulated revenue since 2000/01/01 < 1000 ETH
• Action type is 'mint_asset'
• X's current voting weight <= 75%
• X's current dividend weight <= 90%

If all true, the plugin grants unconditional approval.

In Statutory Script, this translates to:

javascript const vam_statute_2 = {

// Trigger logic
trigger_condition:
    (current_epoch >= toTimestamp('2035/01/01')) & // Time constraint met
    (cumulative_revenue_since(946706400) < 1000000000000) & // Revenue threshold not breached (1000 ETH Gwei scale)
    (action_type == "mint_asset") & // Triggered by asset issuance
    (total_voting_power_percentage(address_x) < 75) & // X's voting share insufficient for takeover
    (total_dividend_power_percentage(address_x) < 90),

// Decision: Approve unconditionally
decision_output: PERMIT,

// Priority
priority_level: 100,

// Approve after simulation check
execution_timing: post_simulation,

}

Case Study 3: Tiered Employee Compensation

Statute 3: Monthly salary disbursement for personnel classified as role level X is fixed at 10 ETH.

Plugin Design: If the action is 'increment_disbursement_pool', the amount is capped at 10 ETH, and the initiator's last such operation was more than 30 days prior, the operation is auto-approved, bypassing sandbox validation.

Statutory Script definition (assuming role level 2 equates to X, with a 30-day grace period):

javascript const payroll_statute_level_2 = { trigger_condition: (action_type == "adjust_disbursement_pool") & // Action matches payroll crediting (operator_role_classification == 2) & // Operator belongs to role level 2

    // Time constraint: gap >= 30 days (2,592,000 seconds)
    (operator_time_since_last_action("adjust_disbursement_pool") >= 2592000) & 
    // Cap constraint: amount added <= 10 ETH (10^22 Gwei equivalent)
    (increment_disbursement_amount <= 100000000000000000000),

// Decision: Approve and bypass simulation
decision_output: PERMIT_AND_SKIP_SANDBOX,
priority_level: 1
execution_timing: pre_simulation,

}

This permits authorized personnel to credit accounts up to the 10 ETH monthly limit without simulation overhead, unless overridden by a higher priority, pre-simulation veto plugin (e.g., if the recipient's account is frozen or they are demoted).

Case Study 4: Governance Voting and Rule Modification

For routine organizational functions, a core directorial group can be established, utilizing voting protocols for key decisions. E.g., admitting a new board member (level 2 token holder):

1. Any entity holding >10% voting power can propose adding a member by issuing one level-2 token, subject to ratification by a 2/3 majority of current board members (governance rule 1).

javascript const admit_board_member = { trigger_condition: (action_type == "mint_asset") & // Action is asset creation (mint_asset_token_level == 2) & // The created asset is level 2 (mint_asset_volume == 1) & // Only one unit is requested (initiator_total_voting_power_percentage >= 10), decision_output: vote_mandated, governance_rule_ref: 1, // Subject to rule 1: 2/3 board approval required priority_level: 100, execution_timing: post_simulation, }

1. Any operator with >7% voting weight can trigger enable_plugins(), requiring unanimous (100%) approval from board members. Such activation attempts are rate-limited to one attempt per 10 days per operator.

javascript const activate_plugin_mandate = { trigger_condition: (action_type == "enable_plugins") & // Action is enabling modules (initiator_total_voting_power_percentage >= 7) & // Initiator meets minimum influence threshold (operator_time_since_last_action("enable_plugins") >= 864000), // 10-day cooling period enforced

decision_output: vote_mandated,
governance_rule_ref: 2,  // Subject to rule 2: 100% board assent required
priority_level: 100,
execution_timing: post_simulation,

}

1. Deactivating plugins 2, 3, and 4 requires the operator to possess >=20% voting power and necessitates approval by 70% of level-0 (common stock) holders based on relative majority (governance rule 3). This action is limited to once every 15 days per operator.

javascript const deactivate_specific_plugins = { trigger_condition: (action_type == "disable_plugins") & // Action is deactivation ( target_plugin_id == 2 | target_plugin_id == 3 | target_plugin_id == 4 ) & // Targeting specific post-simulation modules (initiator_total_voting_power_percentage >= 20) & // Threshold of 20% influence met (operator_time_since_last_action("disable_plugins") >= 1296000), // 15-day cooldown decision_output: vote_mandated, governance_rule_ref: 3, // Subject to rule 3: 70% common stock majority vote execution_timing: post_simulation, }

Case Study 5: Multi-Tiered Asset Structure (Product Tokens & NFTs)

This details how different asset classes carry distinct economic rights, reflecting their purpose:

Tier	Asset Class	Suffrage Weight	Profit Share Weight	Total Issuance Cap
0	Common Equity	1	1	100,000
1	Preferred Equity	20	1	10,000
2	Board Mandate Units	1	0	5
3	Executive Vouchers	1	0	5
4	Non-Voting Shares	0	1	200,000
5	Product Token Alpha (Valued @ 0.01 ETH/unit)	0	0	Unlimited
6	Product Token Beta (Valued @ 10 ETH/unit)	0	0	Unlimited
7-11	Unique Collectible Assets (NFTs)	0	0	1 per Tier

Customers can acquire product tokens or NFTs via process_expenditure() (direct payment) or issue_for_purchase() (payment used as capital contribution).

Defining the fixed price for Product Token Alpha (Tier 5):

javascript const price_rule_token_alpha = { trigger_condition: (action_type == "issue_for_purchase") & // Action is payment-based issuance (issue_for_purchase_token_level == 5) & // Target is Tier 5 asset (payment_price_per_unit >= 10000000000000000), // Price must be >= 0.01 ETH (in Wei)

decision_output: PERMIT_AND_SKIP_SANDBOX,  // Approve immediately
priority_level: 1,
execution_timing: pre_simulation,

}

Defining the minimum price floor for all NFTs (Tier 7 and above):

javascript const price_rule_nft_floor = { trigger_condition: (action_type == "issue_for_purchase") & // Action is payment-based issuance (issue_for_purchase_token_level >= 7) & // Target is Tier 7 or higher NFT (issue_for_purchase_unit_count == 1) & // Mandate single-unit issuance only (current_total_issuance_for_level == 0) & // Ensure only the first instance is priced (payment_price_per_unit >= 10000000000000000000), // Price must be >= 10 ETH (in Wei)

decision_output: PERMIT_AND_SKIP_SANDBOX,  // Approve immediately
priority_level: 1,
execution_timing: pre_simulation,

}

Case Study 6: Dividend Rate Stabilization

Dividend distribution mechanics: 1. A fraction (Y‱) of total operational income is diverted to a distributable cash pool per qualifying transaction. 2. offer_dividend() moves this pool to token holders' individual withdrawal balances. 3. Individual payout = distributable_pool * holder_dividend_weight / total_system_dividend_weight 4. Post-payout, the pool and transaction counter reset.

Statute 6: The dividend yield rate (as a percentage of income) must be maintained above 500 basis points (5%) until the epoch 2030-01-01.

javascript const dividend_stability_statute = { trigger_condition: (action_type == "set_parameters") & // Operation is configuration update (parameter_key_name == "dividendPermyriadPerTransaction") & // Targeting the yield rate parameter (new_parameter_value < 500) & // New rate is less than the 5% floor (current_epoch < 1893477600), // Epoch date < 2030-01-01 (Unix timestamp)

decision_output: VETO,  // Reject setting a rate below the floor
priority_level: 1,
execution_timing: pre_simulation,

}

Case Study 7: Investment Documentation Package (SAFE Example)

A typical venture investment program (Simple Agreement for Future Equity) structure:

1. VC commits 1000 ETH (1,000,000,000,000 Gwei) capital.
2. VC receives 100,000,000 Tier-0 (Common Stock) units and 1 Tier-2 (Board Seat) unit.
3. VC gains authorization to revoke plugins 5, 6, 7.
4. VC gains authorization to activate plugins 8, 9, 10, 11.
5. VC role is escalated to Tier-5 (Majority Shareholder status).
6. Audit Trail: The executed agreement (PDF) should be hashed, stored on IPFS (QmcpxHN3a5HYnPurtuDs3jDfDSg1LPDe2KVBUG4RifcSbC), and permanently logged via DARC's persistent storage for potential technical forensic review.

javascript const investor_address = "0x1234567890123456789012345678901234567890"; // VC Identity

pay_cash(1000000000000, 0, 1); // Capital injection: 1000 ETH equivalent

mint_asset([investor_address], [0], 100000000); // Issue 100M Tier-0 assets

mint_asset([investor_address], [1], 2); // Issue a single Tier-2 asset (Board representation)

revoke_plugins([5, 6, 7], { check_sandbox: false }); // Deactivate specified post-operation modules

activate_plugins([8, 9, 10, 11], { check_sandbox: false }); // Activate newly introduced modules

reclassify_member_role(investor_address, 5); // Elevate role to Tier 5 status

/* Securely record the binding legal documentation via decentralized storage for accountability. / record_persistent_data(['QmcpxHN3a5HYnPurtuDs3jDfDSg1LPDe2KVBUG4RifcSbC']);

Compilation & Deployment Procedures

This project relies on Hardhat and OpenZeppelin tooling. Recommended workflow:

1. Dependency Acquisition

We suggest utilizing pnpm over npm for package management due to performance and space efficiencies, though npm is compatible.

shell
cd darc-framework-root
npm install

1. Contract Compilation

   shell npx hardhat compile

2. Local Test Network Initiation

   shell npm run node

3. Testing Execution

   shell npx hardhat test REPORT_GAS=true npm run test

4. Mainnet/Testnet Deployment

   shell npm run deploy

WIKIPEDIA NOTE: The following text pertains to the TRON blockchain and is irrelevant to the DARC project's technical specification, included only as per source text retention requirement.