OpenVinoDAO

Demo

About

The problem it solves Today's dApps and DAO's are not TRULY decentralized, because they depend upon centralized web2 and web3 components, and the secrets held by their builders. In this project, we built the OpenVinoDAO governance layer with: * Crowdsale contracts that incentivize early investors * 2:1 token-splits * Decentralized infrastructure * DAO managed secrets. Challenge: How can we reward early investors in OpenVinoDAO Solution: Our crowdsale contract is designed to incentivize early investors by offering preferential pricing during the initial token sale phase. Initial Price: The first 1.25 million OVI tokens will be sold at a rate of 2.5 tokens per 1 USDC. This provides early supporters, such as friends, family, and early OpenVinoDAO adopters, with a discounted price to encourage early participation and foster a strong community foundation. Subsequent Price: Once the initial 1.25 million OVI tokens are sold, the price will switch to a 1:1 ratio—1 OVI token per 1 USDC—for the remaining 2.5 million tokens. This tiered pricing structure ensures that early investors receive a better deal, rewarding those who believe in the project early on, while still allowing later investors to participate at a fair market rate once the early phase is complete. Challenge: Tokenomics and Pricing of OpenVinoDAO Tokens One of the significant challenges was determining how to maintain the stability and dynamic nature of the OpenVinoDAO token (OVI). We needed a way to ensure that the price of the token didn’t become too volatile, as this could impact both the cost of staking tokens for wineries and the rebate mechanism for consumers. Solution: We created a system of smart contracts that allows for 2:1 token splits when the price of OVI tokens exceeds 2 USDC and stays at that price for 30 days. This method helps us adjust the total number of tokens in circulation without minting new ones, ensuring that the price remains within a reasonable range and the token holds its value for both wineries and consumers. Challenge: Decentralizing Infrastructure Many DAOs today still depend on centralized infrastructure like cloud hosting, which creates a single point of failure and undermines decentralization. We needed to solve the issue of decentralizing the backend infrastructure for OpenVinoDAO and removing reliance on centralized services. Solution: We developed the Netrabrick, a decentralized hardware node that wineries can run on-site. The Netrabrick integrates several services: Base mainnet execution and consensus clients (using DappNode) IPFS node for data storage. zkSync custom chain for recording winery sensor data. DNS, firewalls, and backup services. By getting wineries to run these nodes, we distribute the infrastructure across many parties, ensuring that OpenVinoDAO operates in a truly decentralized manner, with no reliance on cloud providers. Challenge: Secrets Management and Security In a decentralized system, managing secrets like TLS certificates, database credentials, and API keys is a critical issue. Centralized secrets management systems, like AWS Secrets Manager or HashiCorp Vault, don’t align with the principles of decentralization, as they require trust in a central entity. Solution: We solved this challenge by using OpenBao, an open-source fork of HashiCorp Vault. OpenBao enables us to securely manage PKI infrastructure and secrets across a distributed network of servers running on the Netrabricks. This decentralized secrets management solution ensures that no single party controls sensitive information, and it allows the DAO to delegate or revoke access based on verifiable credentials. This way, if an admin’s access is compromised, the DAO can revoke their access instantly.

How it's made

Challenges we ran into Building base nodes is not as straightforward as it seems! Persistence, and information from the Base discord community helped us reach the finish line. Building the Base Sepolia node on DAppNode and integrating it with OviSync involve several significant challenges. Below are some of the obstacles we encountered: Version Compatibility Issues: One of the primary challenges was ensuring compatibility between the execution client (Reth) and consensus client (Prysm). We faced a fork version mismatch error which prevented proper synchronization. Peer Connectivity and Syncing: During the initial setup, the Base Sepolia node was stuck at block 0, preventing it from syncing with the network. This was primarily due to issues with peer connectivity and the node’s ability to connect to the correct endpoints. Infrastructure and Configuration on DAppNode: The integration of the Base Sepolia node with DAppNode presented additional challenges. DAppNode simplifies node management but required specific configuration for the Base Sepolia node to operate smoothly within the DAppNode environment. We had to ensure that the correct jwt.hex file was properly mounted as a shared docker volume for authentication between the components Maintaining Stability in a Multi-Client Environment: The Base Sepolia node is part of a multi-client environment that also includes op-node. Ensuring stability between Reth, Prysm, and op-node while maintaining synchronization between Base Sepolia and the zkSync custom chain (OviSync) is difficult, to put mildly. Resource Allocation and Performance Optimization: Since the Base Sepolia node was running alongside other critical components, ensuring sufficient resource allocation for performance is crucial. The zkSync custom chain—powered by the OpenVinoDAO OVI token—integrated into the infrastructure for recording winery sensor data, but some challenges remain for production deployment. The integration of the OpenVinoDAO OVI token as the base token for the OviSync zkSync chain adds an additional layer of complexity. We have to ensure that the OVI token is being used for gas payments on the chain while avoiding the need for ETH.