3. Technical Documentation

BlockumDAO’s technical infrastructure is built with versatility and security at its forefront, supporting compatibility across EVM-compatible networks, while currently operating on the Polygon network. This section delves into the architectural design, detailed functionalities of our smart contracts, and guidance for developers on interfacing with BlockumDAO through Web3 technologies.

System Architecture #

• EVM Compatibility: BlockumDAO is architected to be adaptable across any Ethereum Virtual Machine (EVM)-compatible network, offering flexibility in its blockchain foundation. This design choice ensures that the DAO can leverage the specific advantages of different networks as needed.
• Current Operation on Polygon: For efficiency and scalability, BlockumDAO currently operates on the Polygon network. This choice provides lower transaction costs and faster confirmation times, enhancing the user experience for our community members while maintaining robust security and decentralization.

Smart Contract Details #

Each smart contract in the BlockumDAO ecosystem is designed with specific functionalities to support our decentralized governance model, revenue distribution, and operational efficiency:

FGOLToken Smart Contract Technical Documentation #

The FGOLToken, deployed on the Polygon network, represents the foundational asset within the BlockumDAO ecosystem, facilitating governance, incentives, and transactions within the platform. The contract address on the Polygon network is 0xa1B7797F97eE6C928A6Ce0E403f345b68945C6D7.

Key Features and Functionalities #

• ERC20 Standard: The FGOLToken adheres to the ERC20 standard, ensuring compatibility with the broad ecosystem of Ethereum-based tokens for seamless transfers, wallet support, and exchange listings.
• Enhancements: Incorporating extensions from OpenZeppelin such as ERC20Burnable, ERC20Snapshot, and ERC20Pausable, the FGOLToken introduces advanced functionalities:
  • Burnable: Token holders can voluntarily burn their tokens, reducing the total supply and potentially increasing the value of remaining tokens.
  • Snapshot: Supports the creation of snapshots of account balances, which can be used for governance votes, dividend distributions, or other mechanisms that require historical data.
  • Pausable: The contract owner can pause the token transfers in the event of a security concern or major operational update, adding an extra layer of control and security.
• Ownership and Minting:
  • Deployed and initially owned by the GoldOfir, the contract allows for the minting of 1 billion FGOL tokens at the time of deployment. The initial supply allocation is designed to support the ecosystem’s growth and the operational needs of BlockumDAO.
  • The contract includes a minting function, enabling the issuance of additional tokens. However, any additional token minting beyond the initial supply is subject to community approval, demonstrating the commitment to democratic governance within the BlockumDAO ecosystem.
• Metadata URI: Contains a URI pointing to a JSON file with metadata about the FGOLToken. This feature is crucial for providing token information on various platforms, enhancing transparency about the token’s characteristics and uses.
• Transaction Limit per Block: To enhance security and reduce potential transactional spam or manipulation, the FGOLToken implements a limitation on the number of transactions an address can initiate per block. This unique feature underscores the emphasis on operational integrity within the ecosystem.

Governance and Community Approval #

The FGOLToken contract underscores the importance of community governance in the BlockumDAO ecosystem. The mechanism for minting additional tokens beyond the initial supply is designed to be community-driven, requiring approval through a democratic voting process. This aligns with the principles of decentralized governance, ensuring that key decisions, such as the expansion of the token supply, are made collectively by the community stakeholders.

The FGOLToken is a pivotal component of the BlockumDAO, designed with a blend of standard and enhanced functionalities to support a robust and democratic ecosystem. Through its thoughtful design and adherence to best practices in contract development, the FGOLToken facilitates a wide range of activities and governance processes within the BlockumDAO, aligning with the organization’s goals of transparency, security, and community empowerment.

This documentation aims to provide a comprehensive overview of the FGOLToken’s technical aspects and functionalities, serving as a resource for community members, developers, and stakeholders interested in the technical foundation of the BlockumDAO ecosystem.

Vault Contract Technical Documentation #

Contract Address #

• Vault Address: 0x38315D43c29BE340CeA77ba1A9a2d1AFFCb09d16
• LP Token Address: 0xCc2873F0E4F56f3cA8bC3D6D3Cd0B1328816CE5F (SushiSwap LP Token)

Overview #

BlockumVault facilitates the allocation of LP tokens within the ecosystem, playing a pivotal role in the governance and financial mechanisms of BlockumDAO. This contract allows members to deposit LP tokens, participate in governance through locked tokens, and withdraw their holdings, adhering to predefined rules and fees.

Key Variables #

• lpToken: Reference to the LP token managed by the vault, indicating the liquidity provider tokens from SushiSwap.
• goldofirAddress, blockumAddress, whitelabelAddress: Addresses designated to receive specific shares of distributions. They represent the Goldofir, Blockum, and whitelabel beneficiaries, respectively.
• totalLPLocked: Tracks the total amount of LP tokens locked within the vault, representing the collective stake of all participants.
• earlyWithdrawalFee: The fee applied to early withdrawals, variable as decided by the main council in conjunction with Goldofir and the sector-specific council. The standard setting starts at 10%, but it’s adjustable to align with ecosystem goals.
• vestingDuration and vestingCliff: Parameters governing the lock-up period for deposited tokens. By default, the vesting duration is set to 60 months, with a vesting cliff of 30 months, to ensure committed participation.
• Security Features: Alongside the pausable feature, the contract includes measures like automatic withdrawal detection and restrictions on the frequency of withdrawals. These are aimed at safeguarding the vault’s assets and preventing exploitation.
• Governance Integration: The contract is designed to operate in harmony with BlockumDAO’s governance structures. Decisions regarding early withdrawal fees, vesting terms, and distribution percentages are influenced by the DAO’s governance processes, illustrating the contract’s integral role in the broader ecosystem.

Main Functions #

• deposit(uint256 _amount): Allows members to deposit LP tokens into the vault. These tokens are then subject to the contract’s withdrawal terms.
• withdraw(uint256 _amount): Members can withdraw their deposited LP tokens. Withdrawals within the cliff period incur a fee, contributing to the ecosystem’s growth.
• setVestingDuration(uint256 value, TimeUnit unit) and setVestingCliff(uint256 value, TimeUnit unit): Enable the contract owner to adjust the vesting period and cliff, affecting new deposits post-change.
• updateDistributionPercentages(uint256 _goldofirPercent, uint256 _blockumPercent, uint256 _whitelabelPercent, uint256 _communityPercent): Adjusts the reward mechanism’s distribution percentages, ensuring alignment with the evolving objectives of the ecosystem.
• getMemberCount(): Returns the total number of members who have deposited LP tokens into the vault.
• getMemberBalance(address _member): Provides the LP token balance for a specific member, reflecting their current stake in the vault.

Security Features #

• Pausable: Includes mechanisms to pause operations in response to security concerns or significant protocol updates, safeguarding assets.
• Auto-unpause: A feature that automatically resumes contract operations after a predefined delay, ensuring operational continuity even after emergency pauses.
• Ownership Management: Leveraging OpenZeppelin’s Ownable module for secure contract ownership management, ensuring key administrative functions are protected.

Pausable Nature: #

• The contract incorporates a feature allowing it to be paused by the owner in response to emergent issues or security concerns. Unpausing can occur through two mechanisms:
  • Owner Intervention: Using a cryptographic signature, the owner can securely unpause the contract, ensuring control in situations requiring immediate attention.
  • Automatic Unpause: After a minimum predetermined duration following certain events like abnormal withdrawals, the contract is designed to auto-unpause, promoting operational continuity and resilience.

BlockumVault stands as a critical component of the BlockumDAO, balancing the need for secure, transparent liquidity management with the flexibility required for responsive governance. By detailing the functionalities, security features, and governance integration of the contract, this documentation highlights its role in fostering a stable yet adaptable DeFi ecosystem. Through collaborative governance and strategic liquidity management, BlockumVault exemplifies the innovative approaches employed by BlockumDAO to achieve its vision.

Time Representation in Smart Contract #

The BlockumVault contract uses an enumerated type TimeUnit to facilitate the setting of time-related parameters such as vestingDuration and vestingCliff. Here are the specific values you should use when interacting with functions that accept a TimeUnit parameter:

• Seconds (TimeUnit.SECONDS): Input 0 to represent seconds. This is the base unit, so if you want to set a duration or cliff for 300 seconds, you would input 300 along with the TimeUnit.SECONDS indicator.
• Minutes (TimeUnit.MINUTES): Input 1 to represent minutes. For a duration of 10 minutes, input 10 with the TimeUnit.MINUTES indicator. Internally, this is converted to seconds (600 seconds).
• Hours (TimeUnit.HOURS): Input 2 to represent hours. To set a duration of 2 hours, you would input 2 alongside the TimeUnit.HOURS indicator, which translates to 7,200 seconds.
• Days (TimeUnit.DAYS): Input 3 for days. A duration of 1 day would be input as 1 with the TimeUnit.DAYS indicator, converting to 86,400 seconds.

Additional Function Descriptions #

setVestingDuration and setVestingCliff #

These functions allow the contract owner to adjust the vesting parameters for LP token deposits. When calling these functions, specify the time duration or cliff and the corresponding TimeUnit as described above. These adjustments are crucial for managing the liquidity pool’s security and flexibility, ensuring members’ deposits are locked for predetermined periods to align with the ecosystem’s strategic goals.

rescueERC20(IERC20 _token, address _recipient) #

This function allows the contract owner to recover ERC20 tokens that were mistakenly sent to the vault. It’s important to note that this function specifically excludes the ability to rescue the LP token itself, preserving the integrity and security of the liquidity pool. When invoking this function, specify the ERC20 token contract address you wish to rescue and the recipient address to receive the tokens.

Summary #

The BlockumVault contract offers robust functionality for managing LP token deposits, including flexible vesting periods to secure the ecosystem’s liquidity. The inclusion of a rescue mechanism for non-LP ERC20 tokens ensures additional safety for assets inadvertently sent to the contract. These features underscore the contract’s design towards transparency, security, and community trust.

Withdrawal Mechanisms and Security Measures #

Withdrawal Process and Fees #

The BlockumVault contract implements a comprehensive withdrawal mechanism to manage liquidity and ensure member commitment. Withdrawals from the vault are subject to two key time constraints: the vestingCliff and the vestingDuration.

• Before the Vesting Cliff: No withdrawals are permitted. This period ensures that members’ funds contribute to the liquidity pool’s stability for a minimum duration, reinforcing commitment to the ecosystem.
• After the Vesting Cliff but Before Vesting Duration: Members are allowed to withdraw their deposits, but an earlyWithdrawalFee is applied. This fee is a percentage of the withdrawal amount, incentivizing members to remain invested for longer periods. For example, if a member attempts to withdraw 100 LP tokens with an early withdrawal fee of 10%, they would receive 90 LP tokens, and the remaining 10 LP tokens would be allocated as per the contract’s distribution logic.
• After the Vesting Duration: Withdrawals can be made without incurring any fees. This policy rewards members for their prolonged participation in the liquidity pool, allowing them to fully recover their vested funds.

Abnormal Withdrawal Detection #

To protect against sudden liquidity crises and ensure the pool’s integrity, the BlockumVault contract includes an abnormal withdrawal detection system. This system pauses contract operations if it detects withdrawal patterns that could indicate a run on the liquidity pool. The detection mechanism is based on two parameters:

• Total Withdrawal Amount: If the total LP tokens withdrawn within a predefined period exceed a certain percentage of the pool’s total locked LP tokens, the contract automatically pauses. This prevents a large-scale exit that could destabilize the pool.
• Frequency of Withdrawals: Similarly, if the number of withdrawal transactions exceeds a certain threshold within the same period, the contract will pause. This measure is to prevent a panic-induced mass withdrawal scenario.

Example: Suppose the contract is set to trigger a pause if more than 10% of total LP tokens or 10% of members attempt withdrawals within a 24-hour period. If the vault has 10,000 LP tokens locked and 100 members, withdrawals exceeding 1,000 LP tokens or more than 10 individual members withdrawing within 24 hours would automatically pause the contract to prevent potential liquidity issues.

After pausing, the contract can be unpaused manually by the owner or automatically after a set delay, allowing time for assessment and response to the situation. This security measure is crucial for maintaining trust in the liquidity pool’s stability and ensuring that withdrawals do not adversely affect the ecosystem’s overall health.

Conclusion #

The withdrawal policies and security measures embedded in the BlockumVault contract are designed to balance flexibility for members with the liquidity pool’s stability and security. By incentivizing long-term participation and swiftly addressing potential liquidity crises, the contract fosters a robust and secure ecosystem for all participants.

Deposits and Participation in Distributions #

When users deposit LP tokens into the vault (via the deposit(uint256 _amount) function), they’re essentially locking in their capital for a predetermined duration (defined by vestingDuration and vestingCliff). It’s crucial for users to be aware that once they deposit their LP tokens, the tokens are locked until the vesting cliff is reached, and withdrawals within the vesting duration may incur an early withdrawal fee (earlyWithdrawalFee).

For each deposit, the lock-up period is individual and begins at the time of the deposit. This means if a user makes multiple deposits at different times, each deposit will have its own vesting timeline. The amount of tokens deposited directly influences the user’s participation in distributions or airdrops.

Responsibility and Participation #

Users are responsible for understanding the terms associated with their deposits, including the vesting schedule and any potential penalties for early withdrawal. By participating in the system and making deposits, users contribute to the pool’s liquidity and can benefit from distributions or airdrops according to the rules set by the DAO and the contract’s logic.

FGOLDistribution Contract Overview #

The FGOLDistribution contract, deployed on the Polygon blockchain, is designed to allocate and distribute FGOL tokens to members of connected vaults. It interacts with vault contracts (defined by the IVault interface) to determine the distribution of tokens based on predefined rules.

Contract Address: 0x85b4ef82C7ABf0bBFfC87f90CCe1894EA8a8397f

Key Components and Functionalities #

State Variables #

• IERC20 public fgolToken: The FGOL token contract reference.
• IVault[] public allVaults: An array of all vaults that the distribution contract interacts with.
• uint256 public totalFGOLAllocated: Tracks the total FGOL tokens allocated for distribution.
• uint256 public totalFGOLClaimed: Tracks the total FGOL tokens claimed by members.
• address public approvedCaller: An address with special permissions, such as resetting proposal fee status.

Key Functions #

• Vault Management: Functions addVault(address vaultAddress) and removeVault(address vaultAddress) allow the contract owner to manage vaults participating in FGOL distribution.
• Allocation and Distribution: The allocateForDistribution(uint256 totalAmount) function enables members to allocate FGOL tokens for distribution among vaults based on their internal rules.
• Claiming Rewards: Members can claim their allocated FGOL tokens using the claim() function.
• Proposal Fee Management: The contract includes mechanisms to handle proposal fees (proposalCreationFee), including paying fees (payProposalFee()), checking fee payment status (hasUserPaidFee(address user)), and refunding or resetting fee status (resetProposalFeeStatus(address user), refundProposalFee(address user)).

Security and Administration #

• Emergency Unpausing: The contract can be unpaused in emergencies using a special signature via unpauseWithSignature(string memory _message, uint8 _v, bytes32 _r, bytes32 _s).
• Ownership Management: Leveraging OpenZeppelin’s Ownable for secure contract ownership management.
• Token Rescue: Allows the contract owner to recover accidentally sent ERC20 tokens (excluding LP and FGOL tokens) with rescueERC20(IERC20 _token, address _recipient).

Modifiers #

• onlyMember(): Ensures that the caller is a member of any connected vault.
• onlyApprovedCaller(): Restricts certain actions to the approved caller.

Implementation Notes #

• Proposal Creation Fee: Initially set to 0, allowing free proposal creation. The contract owner can update this fee to manage the proposal submission process effectively.
• Distribution Strategy: The distribution logic considers each vault’s locked LP tokens and predefined percentage allocations for different parties (goldofir, blockum, whitelabel, and the community).
• Claiming Process: The claiming process ensures that members can only claim the FGOL tokens allocated to them, promoting fair distribution.

This documentation provides an overview of the FGOLDistribution contract’s architecture and functionalities, designed to facilitate the equitable distribution of FGOL tokens within the system.

BlockumDAO Contract Overview #

Contract Address: 0x37abbc85706f1483f150F1bbEe8a20D55EeA1736

This contract facilitates the decentralized governance of the Blockum project, managing proposals, voting, and administrative functions within the DAO. Members can create, vote on proposals, and participate in the governance process.

Key Features #

State Variables #

• Vault Management: address[] public allVaults keeps track of all vault contracts associated with the DAO. These vaults are critical for determining membership and participation in the DAO.
• Quorum Requirements: Two key variables, minPercentOfMembersForQuorum and minPercentOfCapitalForQuorum, set the thresholds for reaching a quorum in voting, ensuring decisions are made with sufficient participation.
• Proposal and Voting: The DAO supports proposal creation (ProposalDetails[] public proposalDetails) and tracks voting outcomes (ProposalVoting[] public proposalVotings). It handles various aspects like quorum checks, approval, execution status, and fund allocation for proposals.
• Access Control: A mapping (mapping(address => bool) public approvers) identifies approved administrators who can review and manage proposals, adding an additional layer of governance and control.

Key Functions #

• Proposal Creation: Members can initiate proposals related to the project’s sector, providing details, links to presentations, and descriptions for community review.
• Voting: Enables members to vote on proposals, supporting or opposing them, with their votes weighted by their stake in the system.
• Administration: Functions for adding or removing vaults, setting quorum thresholds, and managing approved administrators facilitate flexible and secure DAO management.
• Execution and Review: Proposals can be marked for review, executed if approved, and funded, with mechanisms in place to ensure that decisions follow community consensus.

Security and Administration #

• Pausable: The contract can be paused and unpaused by the owner, allowing for emergency halts in case of security concerns.
• Ownership Management: Utilizes OpenZeppelin’s Ownable for secure ownership and administrative capabilities.
• Proposal Fee Management: Integrates with the FGOLDistribution contract for handling proposal fees, ensuring that members contribute to the DAO’s operations.

Governance Mechanics #

• Quorum Calculation: Provides mechanisms for calculating quorums based on member participation and capital involved, ensuring decisions reflect the broader community’s will.
• Member and Capital Checks: Includes checks for membership status and total capital contributions, critical for voting and proposal creation.
• Emergency Unpausing: Features an emergency unpause function, allowing the contract to be unpaused under specific conditions for continued operation.

Event Logging #

• Logs significant actions and changes within the DAO, such as proposal creation, voting outcomes, and administrative adjustments. This transparency supports auditability and community oversight.

This documentation outlines the Blockum DAO contract’s structure, emphasizing its role in enabling decentralized governance within the Blockum project. Through proposal management, voting systems, and administrative functions, it allows community members to actively participate in decision-making processes, shaping the project’s direction.

Multisignature Ownership #

Ownership Security through Multisignature Wallets

In the interest of decentralization and enhanced security, the ownership of these contracts is assigned to a multisignature wallet. This multisignature wallet requires a minimum of three signatories to approve any transaction, effectively distributing the power to make critical decisions among multiple parties. This arrangement is designed to prevent unauthorized access and ensure that significant actions, such as updating contract parameters or initiating emergency pauses, undergo rigorous scrutiny before execution.

Features and Benefits: #

• Enhanced Security: By distributing ownership among several parties, the risk of single-point failures or unauthorized actions is significantly mitigated. This setup ensures that critical contract operations are executed only after achieving consensus among the designated signatories.
• Decentralized Governance: The multisignature wallet embodies the principles of decentralized governance, aligning with the ethos of blockchain and DAOs. It ensures that decisions reflect a collective agreement rather than individual discretion.
• Operational Integrity: The requirement for multiple approvals adds a layer of operational integrity and transparency, as every action taken by the contract owner is recorded and verifiable on the blockchain.
• Emergency Response: In the event of a security concern or critical operational necessity, the multisignature wallet facilitates a coordinated response, ensuring that any measures taken, such as pausing the contract, are duly considered and agreed upon by the stakeholders.

Implementation: #

The multisignature wallet set as the contract’s owner is configured with predefined security parameters, including the number of signatories and the minimum number of signatures required for transaction approval. These parameters are chosen to balance operational efficiency with security considerations, ensuring that the contract can respond effectively to evolving needs while maintaining stringent security standards.

This multisignature ownership model is a cornerstone of the contract’s security and governance framework, reflecting a commitment to accountability, transparency, and community-driven decision-making.

4. Products and Services

Product Offering

Blockum DAO offers an innovative suite of services and functionalities designed to foster the growth of startups and promising business opportunities within the decentralized finance ecosystem. Our aim is to democratize access to investment opportunities, leveraging blockchain technology to empower our community and contribute to sustainable global economic growth.

a. Token Utilization and Liquidity Pools

Blockum DAO’s ecosystem is centered around the strategic use of FGOL Tokens and their integration into liquidity pools, specifically within the SushiSwap platform. The primary mechanism for governance within our DAO is through the allocation of LP (Liquidity Provider) Tokens, which are obtained by contributing to the liquidity pool composed of FGOL Tokens and WETH (Wrapped Ethereum). This process underscores our commitment to a decentralized, community-driven approach, allowing members to participate in governance decisions by allocating their LP Tokens to the Blockum DAO smart contract.

b. Fostering Mechanisms

Blockum DAO is dedicated to identifying and supporting innovative business opportunities and startups. It is important to note that Blockum DAO itself does not directly invest in these ventures. Instead, investment efforts are independently undertaken by GoldOfir, which uses its resources to foster selected projects. This process is independent of Blockum DAO’s community funds, ensuring a clear separation and no custody of community capital by either Blockum DAO or GoldOfir.

c. Participatory Governance

Governance within Blockum DAO is exercised through the allocation of LP Tokens, ensuring community involvement in strategic decision-making. This governance model ensures transparency and collective participation, core principles that define our organization.

User Guides and Support

Understanding the importance of accessibility and ongoing education, Blockum DAO provides an array of user guides and tutorials. These resources aim to assist members in navigating our ecosystem, from token allocation to active governance participation and project support. For queries not covered in our guides, our support team is available for further assistance, ensuring all community members can effectively engage with our platform.