# Network Rewards & Operator Economics Source: https://covalenthq.com/docs/cxt/network-rewards ## Recap: The CXT Economic Flywheel CXT is the economic core of a functioning, revenue-generating data network. Every component reinforces the others: * **Fixed supply** with no inflation and no remaining unlocks eliminates dilution risk. * The **revenue flywheel** converts real product usage into CXT demand. * The **Strategic Reserve** locks CXT off the market, creating deflationary pressure. * **Staking** secures the Network while providing yield. * **Governance** ensures the community controls the protocol's evolution. As autonomous AI agents become the dominant consumers of on-chain data, the demand for verifiable, structured, sub-second blockchain data will grow exponentially. CXT is how that demand translates into economic value for every participant in the Covalent ecosystem. ## How Operators Earn The Covalent Network compensates Operators who perform verifiable work: extracting, refining, and serving blockchain data. Network Operators are rewarded in CXT for honestly fulfilling their roles on the Network. The two primary factors that determine an Operator's earnings are: 1. **Stake weight:** The more CXT an Operator has staked (including delegated stake), the greater their opportunity to perform work and earn rewards. Stake acts as both a security bond and a prioritization signal. 2. **Work performed:** Operators earn in proportion to their actual contribution — the number of Block Specimens produced, Block Results refined, or queries served. Operators who fulfill multiple Network roles have access to additional reward streams. This dual model ensures that rewards flow to participants who are both economically committed and actively contributing to the Network's data pipeline. ## The Emission Model In the Network's early phase, staking rewards are funded by the Staking allocation: 80 million CXT (8% of total supply) set aside at genesis to bootstrap Network participation for up to 4 years. ### Epoch-Based Emissions Rewards are distributed over the course of an epoch, defined as a 24-hour period. Each epoch, a set amount of CXT is emitted from the Staking Contract Reward pool. This pool is filled from the Staking allocation periodically. The reward emission rate is denominated in CXT per epoch, which means the effective staking yield (APY) fluctuates as the total amount of staked CXT changes. When more CXT is staked, the yield per token decreases; when less is staked, yield per token increases. Historically, the APY has ranged from 8% to 18%. The CXT emission rate is monitored and updated via a governance process. This ensures that as the quantity of staked CXT grows (or shrinks), the proof-of-stake validation remains sustainable and that a reasonable staking yield is maintained over time. For full details on the emission schedule, see the [Emission Schedule documentation](/docs/resources/emission-schedule). ## Operator Reward Models The Covalent Network has two primary production roles: Block Specimen Producers (BSPs) and Block Result Producers (BRPs). Each produces a distinct data artifact that the Network requires, and each has its own reward formula. In the long run, the price for these data artifacts will be determined by the market, with Query Operators being the primary purchasers. However, during the current bootstrapping phase, Covalent acts as the sole buyer of Block Specimens and Block Results, setting a fixed price for each. ### Block Specimen Rewards Block Specimen Producers extract raw, provable blockchain data and upload it to storage. To determine the price of a Block Specimen, the Network considers the number of Block Specimens produced and the number of BSP Operators participating. **Reward formulas:** The price a BSP Operator receives per Block Specimen is proportional to their share of the total BSP stake: ``` block_specimen_price = token_emission_rate × (bsp_Operator_stake / total_bsp_stake) ``` The total reward a BSP earns per epoch is the specimen price multiplied by the number of specimens they produced: ``` bsp_reward_per_epoch = block_specimen_price × num_specimens_produced ``` Expressed formally, the total reward for BSP Operator *i* across all specimens in an epoch is: $\text{bsp\_operator\_reward}_i = \frac{\text{total\_stake}_i}{\sum_{j=1}^{n} \text{total\_stake}_j} \times \left( \text{artifact\_reward\_per\_specimen} \times \text{num\_bsps} \right)$ In plain language: an Operator's reward share is proportional to their stake relative to the total stake of all BSPs, multiplied by the total reward pool allocated to Block Specimen production for that epoch. Operators with a larger stake earn a larger share. Operators who produce more specimens earn more in absolute terms. ### Block Result Rewards Block Result Producers (also called Refiners) take raw Block Specimens and transform them into structured, queryable data — the refined output that ultimately serves API requests. The reward model mirrors the BSP structure but applies to the refiner pool. **Reward formulas:** The price a BRP Operator receives per Block Result is proportional to their share of the total refiner stake: ``` block_result_price = token_emission_rate × (refiner_Operator_stake / total_refiner_stake) ``` The total reward a BRP earns per epoch: ``` refiner_reward_per_epoch = block_result_price × num_results_produced ``` In plain language: the same stake-weighted, production-proportional model applies. Refiners who stake more and produce more Block Results earn proportionally greater rewards. ## Operator Commissions Operators who accept delegated stake can charge a commission — a percentage of the rewards earned on delegated tokens. This commission compensates Operators for the cost of running infrastructure and maintaining uptime. The commission rate is set by each Operator individually. When delegating CXT, token holders should evaluate an Operator's commission rate alongside their performance history, uptime, and total stake when choosing where to delegate. Operator Commissions can be clearly seen on the [Covalent Network Staking Dashboard](https://www.covalenthq.com/staking/). ## Delegation Rewards Token holders who do not wish to operate infrastructure can delegate their CXT to a Network Operator and earn a share of that Operator's rewards. The Delegator's share is proportional to their contribution to the Operator's total stake, minus the Operator's commission. Delegation is designed to be accessible; there is no minimum CXT requirement to delegate. This means any CXT holder can participate in securing the Network and earning yield, regardless of the size of their holdings. ## Staking Requirements by Role The Network defines distinct roles for participants who stake CXT, each serving a specific function in the data pipeline: | **Operator Role** | **Primary Function** | **Min / Max CXT Stake** | **Receives Delegation?** | | ------------------------------- | ---------------------------------------------------------------------- | ----------------------- | ------------------------ | | Block Specimen Producers (BSPs) | Extract raw, provide data from blockchains and upload to storage | 175,000 / 500,000 | Yes | | Block Result Producers (BRPs) | Refine and transform raw block specimens into queryable data | 35,000 / 70,000 | No | | Query Node Operators | Index refined data and serve final API queries to end-users | Varies by Operator | Yes | | Delegators | Delegate stake to an Operator to earn rewards without running hardware | No minimum | N/A | ## Key Parameters at a Glance | **Parameter** | **Value** | | ------------------------------ | -------------------------------------------------------------------------- | | Reward cycle (epoch) | 24 hours | | Staking APY (historical range) | 8% – 18% | | Unstaking cooldown | 14 days | | Slashing | Active — malicious or dishonest Operators lose a percentage of their stake | | Bootstrap reward source | Staking allocation (80M CXT, up to 4-year runway) | | Long-term reward source | Network usage fees (free-market pricing for data artifacts) | | Strategic Reserve outflows | Governance-gated; Long-term reserve | ## Summary Operators earn in proportion to their economic commitment (stake) and their productive contribution (work performed). Delegators participate without running infrastructure. And the entire system is moving toward a future where the value of verifiable data — not protocol subsidies — sustains the Network. Combined with the CXT Economic Flywheel and Strategic Reserve, these mechanics create a complete economic system: one where every API query, every chain integration, and every AI agent request strengthens the Network and rewards those who power it. ← Back to [Tokenomics of CXT](/docs/cxt/tokenomics) # Overview of CXT Source: https://covalenthq.com/docs/cxt/overview At the core of the Covalent ecosystem is the Covalent X Token (CXT), which is integral to the decentralized long-term data availability network. CXT is the native token of the network wherein all settlements are denominated in this currency. CXT's functions can be broadly broken down into the following: * **Staking**: Operators, who first have to meet the minimum staking requirement to become such, are compensated in CXT for honestly fulfilling their roles (or role), and performing work on the network like validating data requests, indexing blockchain data, and responding to queries. Furthermore, token holders who wish to contribute to securing the network but don't wish to run node infrastructure, can delegate to a Network Operator and earn staking rewards in CXT. * **Governance**: Those who hold CXT and have a vested interest in the network will be able to vote using CXT for on-chain proposals put forward by the community. ## Contract addresses | Contract | Network | Address | | -------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | CXT Contract Address | Ethereum | [0x7ABc8A5768E6bE61A6c693a6e4EAcb5B60602C4D](https://etherscan.io/address/0x7ABc8A5768E6bE61A6c693a6e4EAcb5B60602C4D) | | CXT Uniswap Pool | Ethereum | [0xc783d210c483d76d158fd502af6b48439ffed9c5](https://etherscan.io/address/0xc783d210c483d76d158fd502af6b48439ffed9c5) [GeckoTerminal](https://www.geckoterminal.com/eth/pools/0xc783d210c483d76d158fd502af6b48439ffed9c5) [DexScreener](https://dexscreener.com/ethereum/0xc783d210c483d76d158fd502af6b48439ffed9c5) | ## Using your CXT How to participate as an operator or as a delegator to secure the network. How to participate in governance and shape the network. ## CXT operating on the Covalent Network ### Infrastructure Currency CXT is not a payment token, rather a means of settlement (settlement will take place on MoonBeam). In the future, when an individual makes a call for the API, they will pay in a US denominated stablecoin such as USDC. The contract will then perform a market buy of CXT using this USDC, driving demand for the token. The CXT is then distributed to the wallets of nodes as a reward for answering the API query. 1. The application/developer loads their deposit account with stablecoin assets into the network smart contract. 2. The application queries the Covalent API. 3. A check is made to verify that there are sufficient funds in the deposit account before sending the respective query request to operators. 4. The query is sent to the Query operator to fulfill the request. 5. The desired data is sent back to the application. 6. An entry is made on the Moonbeam ledger regarding the data that is being consumed, and which operator(s) are fulfilling the request and their cost. 7. The balances between the network contract, CXT and the work performed are reconciled. 8. The USD funds are drawn down from the developer's deposit account and swapped for CXT via a market buy mechanism and settled against a validator's outstanding balance. The reason for implementing a stablecoin mechanism is that: * Stablecoins are the most highly adopted tokens in the web3 ecosystem. * Enterprise customers don't want to hold a token that is susceptible to volatility on their balance sheets. * It makes measuring the expense of using the Covalent API easier to budget for users. * The greater number of API queries, the greater the demand and buy pressure for CXT that exists on the Covalent Network. The greater number of API queries, the greater the demand and buy pressure for CXT that exists on the Covalent Network. ### Staking Staking is an essential feature of the Covalent Network. All Network Operators have to meet the minimum staking requirement. This mechanism is in place to promote and ensure correct behaviour in the Covalent Network. If Network Operators are ever malicious or dishonest, a percentage of their staked amount will be slashed. Furthermore, Network Operators stand to earn more CXT by providing utility to the network. More information on Covalent Network staking can be found [here](/docs/cxt/staking/). #### Audits * [Current Audit and Security Reports](/docs/resources/audits/) # CXT Staking Guide Source: https://covalenthq.com/docs/cxt/staking-guide How to Stake CXT to secure the Covalent Network. The primary way to stake CXT is through the Covalent Network [Staking Dashboard](https://www.covalenthq.com/staking/#/). Here, you can stake your CXT to a number of Covalent Network Operators. As a reward for doing so, you stand to earn CXT proportional to how much you have staked. Staking has now migrated to the Ethereum Mainnet from Moonbeam. There is no longer a need to bridge your CQT(deprecated) across in order to participate in securing the network. ### Getting Started with the Covalent Network Dashboard To get started with the dashboard, navigate to the Covalent Network [Staking Dashboard](https://www.covalenthq.com/staking/#/). You will be prompted to connect your wallet. If you have not already, you will need to connect to the Ethereum Mainnet network via your wallet. On the staking dashboard, you will be able to delegate to network operators, modify existing staked positions, and get an overall glimpse of your staking activity. #### Stake your CXT to a Network Operator Upon connecting your wallet to the Covalent Network [Staking Dashboard](https://www.covalenthq.com/staking/#/). As a Delegator, you can delegate to any Network Operator by staking tokens and adding to the Operator's stake. * You should see a number of Network Operators, all of which perform a specific network role as Block Specimen Producers. * On the dashboard, you can view the name, operator's staked amount, commission rate, APY, amount of CXT delegated to this operator, and the delegation room available. * In selecting a Network Operator, it is important to consider the commission rate and delegation available to stake. * To stake, select an operator, click stake and choose the amount of CXT you wish to delegate. * From there, you have to first approve the contract interacting with your wallet and second, make and confirm the transaction. Once you have completed both of these actions, you have officially staked your CXT. When you return to the Staking Dashboard after successfully staking your CXT, you should be able to view your staked position. #### Topping Up your staked amount * To top up your staked amount: * On the staking dashboard, select the ‘Top Up’ prompt after delegating your CXT. * Here, you can either: * Stake more CXT from your wallet to the Operator. This follows the same process as described above. * Or, if you have rewards you wish to claim and stake, you can do so. * The new staked amount should now be reflected on the dashboard. #### Redeeming your CXT rewards Rewards can be redeemed immediately. There is no cooldown period for rewards. To redeem: * Under 'Staked', a tab labeled 'Available to Redeem' is displayed where you can view how much you can redeem. This is the interest you have earned on the staked amount. * Select 'Redeem', choose how much you wish to redeem, pay the transaction fee and the reward amount is deposited into your wallet. This can be the original wallet you used or a beneficiary address. * Note, the redeem amount is the Total Earned minus the Commission Fee of the operator you have staked with. #### Unstaking your CXT There are some points to consider when unstaking your delegated CXT: * For Delegators, there's an unstaking period of 14 days. * For Operators, there's unstaking period of 6 months. * As a reminder, the length of both of these figures can be changed by the contract owner. * Note that this is different from redeeming rewards. Redeeming rewards involves claiming your interest earned whereas unstaking involves removing a portion or your full amount of staked CXT. **Scenario 1:** Delegator chooses to unstake themselves * Under 'Unstake', select 'Transfer out'. * You will be presented with the below prompt. Here you can select how much you wish to undelegate. Then it is a matter of paying the transaction fee. * Once the transaction has been confirmed, the cooldown period will begin. * Once the cooldown period is over, you can transfer your unstaked CXT to your wallet. **Scenario 2:** My operator got disabled A Network Operator may become disabled for two 2 reasons: 1. They unstake and no longer operate on the network 2. Misbehave In both cases: * You can choose to unstake or simply move the staked amount to another operator. * It is the Delegator's sole responsibility to monitor if the Operator they have delegated their CXT to has been disabled or not. #### Redelegate your CXT from a disabled operator to a active operator Upon connecting your wallet to the Covalent Network [Staking Dashboard](https://www.covalenthq.com/staking/#/). As a Delegator staked with a disabled operator, you will see a disabled note and highlighted unstake button. Click on the Unstake/Unstake All button and you will be prompted to confirm the transaction. After the transaction is confirmed, go to the **Unstaked** tab. Here, you’ll see two options: **Redelegate Now** and **Transfer Out**. **Transfer Out** sends your unstaked CXT back to your wallet. Note that there’s a **14-day cooldown** before the tokens are fully available. To keep staking, choose **Redelegate Now** after the **3-day unstake recovery period** ends. This lets you move your CXT directly to an active operator without the 14 days wait. #### Recover your Unstaked amount During the cooldown period that follows unstaking your CXT, you can go back and recover the unstaked amount; staking back the unstaked amount to the operator after the 3 days cooldown period is completed. That’s it! Now you’ve successfully delegated to a Network Operator, updated the delegation amount, and then removed the delegation. You have all the tools necessary to get started with staking on the Covalent Network! # Tokenomics Source: https://covalenthq.com/docs/cxt/tokenomics ## The Tokenomics of CXT: Powering the Verifiable Data Economy for Agentic AI As autonomous AI agents become the dominant consumers of on-chain data, the infrastructure that feeds them must be trustworthy, structured, and economically sustainable. The Covalent Network provides a modular data infrastructure layer delivering verifiable, structured blockchain data at sub-second speeds across 230+ chains. At the center of this system is the Covalent X Token (CXT), the economic engine that aligns every participant — from the data producers and verifiers, to developers and AI agents — around a single, demand-driven value loop. CXT is the settlement currency of a data economy where every API call, every agent query, and every chain integration compounds value back to the Network and its stakeholders. With a fixed supply, no minting token unlocks, active revenue-backed buybacks, and a Strategic Reserve, CXT is poised for structural deflation. ## What CXT Does: The Three Pillars CXT serves three interconnected functions within the Covalent Network. Together, they form a coherent economic system where governance, security, and revenue reinforce one another. ### Governance CXT grants holders the right to propose and vote on changes to the Network. This includes decisions about new data sources, chain integrations, staking parameters, geolocation requirements, and data modelling standards. Governance follows a two-stage process: proposals are first discussed on the public Governance Forum, then move to a formal, gasless vote on Snapshot where CXT holders make binding decisions. Any wallet holding CXT is eligible to vote, with voting power proportional to the amount held. This framework has already driven significant protocol changes, including the staking migration to Ethereum and adjustments to staking parameters allowing CXT holders to be stewards of the Network's evolution. ### Staking & Network Security CXT is the staking asset that secures the Covalent Network. Network Operators must stake CXT as an economic bond before they can produce, refine, or serve data. If an Operator behaves maliciously or dishonestly, their CXT rewards are slashed. This mechanism guarantees the integrity of the data flowing through the Network — a non-negotiable requirement for AI systems that depend on verifiable inputs. Token holders who wish to contribute to security without running infrastructure can delegate their CXT to an Operator and earn staking rewards. Staking also functions as a primary token sink. ### Network Access & Value Accrual CXT is the medium through which all economic value flows within the Covalent Network. When developers, enterprises, or AI agents query the GoldRush API or use Covalent's data products, a portion of the revenue generated is used to purchase CXT from the open market. That purchased CXT is used to support the Strategic Reserve. This creates a direct, measurable link: more usage → more revenue → **more CXT demand** → more value accrued to stakeholders. Additionally, as an ERC-20 token on Ethereum, CXT is inherently composable with the broader DeFi ecosystem, enabling integration into lending protocols, liquidity pools, and other financial primitives. ## Supply & Distribution: A Fixed, Transparent Foundation ### Fixed Supply with No Inflation CXT has a total supply of 1,000,000,000 tokens, all minted at genesis. The tokenomics are non-inflationary by design. While the Ethereum smart contract includes a minting function, it is inactive by default and can only be activated through a formal governance vote. This preserves the token's deflationary foundation while retaining flexibility for the community to make deliberate, transparent decisions about any future supply changes. ### Initial Token Allocation CXT is strategically distributed across stakeholders. It is fully vested with vesting schedules designed to ensure long-term alignment. | **Category** | **Token Allocation** | **% of Total Supply** | **Vesting (Months)** | **Cliff (Months)** | **Vesting Details** | | -------------- | -------------------- | --------------------- | -------------------- | ------------------ | -------------------------------------------------------------- | | Seed | 100,000,000 | 10.0% | 18 | 6 | 25% released at 6, 12, 15, and 18 months | | Private Sale | 203,846,154 | 20.4% | 9 | 0 | 25% at TGE, then at 3, 6, and 9 months | | Private Sale 2 | 29,305,142 | 2.9% | 9–24 | 0–6 | Varies; 25% released at intervals of 3–6 months | | Public Sale | 34,314,063 | 3.4% | 0–24 | 0–6 | Varies by tier; from no lockup to 24-month linear vest | | Team | 143,636,035 | 14.4% | 48 | 12 | 25% earned at 1-year cliff, then linear vesting over 36 months | | Advisors | 20,000,000 | 2.0% | 24 | 13 | Vesting occurs between months 13 and 24 | | Reserve | 188,898,607 | 18.9% | 45 | 0 | Gradual release schedule over 45 months | | Staking | 80,000,000 | 8.0% | 53 | 6 | 48-month vest following a 6-month cliff | | Ecosystem | 200,000,000 | 20.0% | 47 | 0 | 48-month vest starting from TGE | | **Total** | **1,000,000,000** | **100.0%** | **—** | **—** | **—** | ### Circulating Supply As of Q2 2026, over 95% of the total CXT supply is in circulation, signaling a mature token economy with minimal dilution pressure from early investor unlocks. The remaining non-circulating supply is held in publicly auditable wallets for the Ecosystem fund, Reserve fund, and future staking rewards. The circulating supply can be [independently verified on-chain](https://www.covalenthq.com/staking/): > **Circulating Supply = 1,000,000,000 − (Ecosystem Fund + Reserve Fund + Unvested Staking Rewards)** This transparency means anyone can audit the supply at any time. ## The CXT Economic Flywheel: From Usage to Value CXT's fundamental value is demand-driven. The economic flywheel converts real-world product usage into structural token demand through a programmatic buyback mechanism. ### How the Flywheel Works Developers, enterprises, and AI agents use Covalent's data products — GoldRush APIs, SpeedRun, and chain-level integrations — and pay in fiat or stablecoins like USDC. This is a deliberate design choice: stablecoin-denominated pricing removes volatility risk for enterprise customers and makes data costs predictable and easy to budget, while stablecoins themselves are the most widely adopted tokens in the web3 ecosystem. A significant portion of this revenue then fuels the value accrual engine: a programmatic buyback of CXT from the open market. Purchased CXT is directed to the Strategic Reserve — a multi-year locked vault that removes tokens from circulation. The Reserve supports the long term future of the ecosystem; future use — whether to enhance network security, make ecosystem grants, or for other use — is deferred to when market conditions are conducive. The result is elegant: users pay in dollars, and every dollar spent triggers CXT buy pressure. The more queries, the more demand. Usage and token value become mathematically linked. ### Flywheel Metrics The scale of the buyback program is transparently tracked via quarterly reports and on-chain dashboards: * In 2025 alone, over \~17 million CXT has been purchased through offchain revenue-funded buybacks. * An additional \~9.05 million CXT has been removed from circulation through daily automated on-chain buybacks (\$1,000/day). The flywheel is operational and growing. ## The Covalent Strategic Reserve In October 2025, Covalent announced the launch of the **Strategic Reserve** which is a long-term initiative that transforms the buyback program into a durable reserve of CXT that acts as an additional sink (complementary to the staking program). This represents a structural evolution in how the Network captures and retains value. ### How It Works CXT purchased through both on-chain and offchain buybacks is directed into the Strategic Reserve — a multi-year program that removes tokens from circulation. Revenue from chain integrations, ecosystem grants, GoldRush API usage, SpeedRun, and community campaigns all feed into the reserve. **Key parameters:** * **Reserve goal:** \~10% of total supply (>100 million CXT), accumulated primarily through offchain periodic buys for execution efficiency. * **Vault model:** Multi-year timeframe that limits circulating supply. Value moves in and remains locked. * **Governance-gated outflows:** Potential outflows — whether for strategic ecosystem grants or supply reduction via burns — to require separate governance votes. * **Transparency:** The reserve balances and inflows will be viewable on the CXT Dashboard. * **Future burns:** The merits and challenges of token burns are being evaluated. Once the reserve approaches or exceeds its target, burns may be introduced through a governance proposal. ### The Deflationary Trajectory With no remaining token unlocks, an expanding revenue base, active buybacks, and a locked reserve absorbing purchased tokens, CXT sits on a structurally deflationary trajectory. Additional usage means additional CXT gets removed from the circulating supply, a mechanism that fundamentally strengthens the token's economic position over time. As the revenue flywheel accelerates — driven by new chain integrations, SpeedRun adoption, and AI Agent demand — the rate of value capture into the reserve accelerates with it, potentially decreasing the circulating supply. ## Staking: Securing the Network, Earning Rewards Staking is the cornerstone of the Covalent Network's security model and data verifiability. In this Proof-of-Stake system, Operators and Delegators lock CXT as an economic bond guaranteeing their honest participation. Operator and Delegator roles and detailed reward formulas and Operator economics are fully described in the section on [Network Rewards & Operator Economics](/docs/cxt/network-rewards). ### Staking Rewards and Airdrop Program Stakers earn a variable Annual Percentage Rate (APY), historically ranging from 8% to 18%, depending on the total amount staked in the Network and the reward emission rate. Staking is facilitated through the official [Covalent Staking Dashboard](https://www.covalenthq.com/staking/). To ensure Network stability, unstaking requires a 14-day cooldown period during which tokens do not earn rewards. Introduced in mid-2024, the Ecosystem Airdrop Program adds a powerful dimension to CXT staking. Beyond earning CXT rewards, stakers become eligible to receive token airdrops from Covalent's partner projects. This transforms staking from a single-asset yield mechanism into a gateway for portfolio-level exposure to the Covalent ecosystem and gives partner projects access to an engaged, committed community of CXT stakers. The inaugural airdrop with Taiko distributed \$100,000 worth of TAIKO tokens to eligible CXT stakers. ## Self-Sustainability and Growth The Covalent Network is designed to transition from bootstrapped rewards to a fully self-sustaining economic model. The trajectory is clear: Today, staking rewards are funded by the initial Staking allocation (80M CXT) while protocol revenue builds the Strategic Reserve. In the medium to long term, as GoldRush API usage, SpeedRun adoption, and chain integration revenue grow, the Strategic Reserve will accumulate significant value. The community, through governance, will determine how best to deploy these funds: whether as supplemental staking rewards, ecosystem grants, token burns, or other strategic initiatives. At maturity, the Network becomes a fully self-sustaining data economy. Users pay Query Operators for API access, Query Operators pay into a Network fund proportionate to the data they consume. That fund pays out to production Operators (Block Specimen Producers, Block Result Producers) as Network rewards. The entire cycle runs on economic demand, not subsidies — with the Strategic Reserve serving as a governance-controlled treasury backing the Network's long-term health. ## New Revenue Streams: The Agentic AI Thesis The CXT flywheel is designed to be extensible. Every new product and revenue stream that Covalent launches feeds directly into the buyback mechanism, accelerating value capture for the entire ecosystem. ### SpeedRun Launched in Q4 2025, SpeedRun is a visual, no-code platform for building and scaling full-stack on-chain applications and autonomous agents. As SpeedRun moves from beta to general availability, its revenue flows into the CXT buyback program. ### The AI Agent Opportunity The rise of autonomous AI agents represents a paradigm shift in how on-chain data is consumed. Agents need data that is structured, verifiable, and available at sub-second latency — exactly what Covalent's infrastructure delivers. The more agents that exist, the more the flywheel spins. To capture this opportunity the GoldRush API launched the Vibe Coding tier, a low cost tier designed to service the blockchain data needs of agents and vibe coding tools. Future revenue streams on the horizon include transaction fees from agent actions (x422 payments) and other applications that build on Covalent's data pipeline and inference layer. Each of these will plug into the same economic loop, compounding value into CXT. This is why CXT is positioned not just as a data infrastructure token, but as the economic layer for the agentic AI era where machines are the primary consumers of verifiable data. ## Security & Audits Security is foundational to CXT. The token contracts have been audited by Quantstamp and Hacken, and all high-level issues have been addressed. Current audit and security reports are available on the [Covalent documentation site](/docs/resources/audits). ## Contract Addresses | **Contract** | **Network** | **Address** | | ------------------ | ----------- | -------------------------------------------- | | CXT Token Contract | Ethereum | `0x7ABc8A5768E6bE61A6c693a6e4EAcb5B60602C4D` | | CXT Uniswap Pool | Ethereum | `0xc783d210c483d76d158fd502af6b48439ffed9c5` | | CXT Aerodrome | Base | `0x923bebd9fbcaf0f85251a3d5a11bf5bfaa19942f` | Pool analytics are available on [GeckoTerminal](https://www.geckoterminal.com/) and [DexScreener](https://dexscreener.com/). Next: [Network Rewards & Operator Economics](/docs/cxt/network-rewards) — Detailed reward formulas, epoch mechanics, and the Operator reward model. # Introduction Source: https://covalenthq.com/docs/introduction Covalent is the leading modular data infrastructure layer that’s dedicated to solving the Long-Term Data Availability and the verifiability problem in AI. Hero Light Hero Dark The Covalent Network represents the progressive decentralization of Covalent towards a community-owned and community-run protocol. A multi-sided platform designed to eventually be self-sufficient, the Covalent Network works by capturing and indexing blockchain data and storing it across multiple points on the network. Anyone can then access this data instantly through querying the GoldRush API (formerly known as the Unified API). The Covalent Network has the following capabilities: * Compatible with industry standard data tools * Multi-chain compatible * Storage efficient * Network efficient * Low resource requirements to run on commercial / retail infrastructure ### Building for Ethereum's Long-term Data Availability Covalent defines long-term data availability as the sustained accessibility and availability of historical data on a blockchain network over extended periods of time. While Ethereum’s historical data has always been available directly through the client, this is changing. Due to Ethereum adopting rollups as well as other protocol improvements like [Danksharding](https://ethereum.org/en/roadmap/danksharding/) (data blobs required for validation are deleted after 18 days) and state expiry ([EIP-4444](https://eips.ethereum.org/EIPS/eip-4444)), the responsibility of providing historical data moves outside the Ethereum core protocol. The Covalent Network assumes the responsibility of ensuring long-term data availability. It achieves this by offering a decentralized, cryptographically secure data availability network that allows developers to access comprehensive historical and real-time data for Ethereum as well as other base layers. By leveraging innovative technologies such as the open-sourced Block Specimens & Block Results the Covalent Network empowers anyone to build a full canonical representation of a blockchain, host a database with a standardized schema, or seamlessly query data via the GoldRush API (formerly known as the Unified API). ### A Network Built on Data Verifiability At the core of the Covalent Network is data verifiability which is achieved by employing cryptographic proofs. For every piece of work or transformation completed on the Covalent Network, a respective proof is created ensuring that Network Operators behave honestly and provide data that is accurate. The Covalent Network is one of the first data middleware protocols to employ a proof-based system to ensure data verifiability. This is not only a novel feature of the Covalent Network but an essential mechanism in rebuilding the new foundations of the web. #### Built for Modularity and Extensibility The Covalent Network decouples the data storage layer of blockchains via “Block Specimens" - a novel, canonical data storage format that together represents the blockchain state. Further downstream enrichment of blockchain data like tracing and execution can be (re-)run on Block Specimens without the need of running a resource-heavy node. Furthermore, the standard data model exposed by the block specimen drives composability and jump-starts innovation when anyone can remix, fork and wrap data just like any other asset. Understand the different node roles and how to operate them. Overview of CXT & guide on Staking. Links to all audit reports for the Covalent Network. **Interested in helping the Covalent Network grow?**

Apply to become a Covalent Network Operator today [Learn More](https://app.deform.cc/form/c4dfdd2c-3308-4eb9-9e70-5567126d97d1) # Block Result Producer Onboarding Source: https://covalenthq.com/docs/nodes/block-results-producer-onboarding/brp-onboarding-home The Block Result Producer is a concurrent Block Specimen data processing framework designed for scalable and verified data transformations. Block results are only one of the many possible outputs which are complete representations of the actual blocks being produced on the Ethereum blockchain (that can be queried using an RPC call to an Ethereum node client like `erigon` and `go-ethereum`) and some additional useful fields. The [Block Result Producer Whitepaper](/docs/resources/block-result-producer-whitepaper) goes into detail on its purpose and mission. Running the BRP stack involves running three main pieces of infrastructure, 1. [BRP](https://github.com/covalenthq/refiner)
2\. [das-pinner](https://github.com/covalenthq/ewm-das)
3\. [evm-server](https://github.com/covalenthq/erigon)
These coordinate and execute a transformation pipeline per Block Specimen. Running these nodes are not as disk I/O (or cpu/memory) intense as running [bsp-geth](https://github.com/covalenthq/bsp-geth) and [bsp-agent](https://github.com/covalenthq/bsp-agent) on local machines, However they do require sufficient bandwidth for access to distributed store resources and sending transaction proofs using ethereum clients - connecting to our EVM public blockchain partner [Moonbeam](https://moonbeam.network/). We shall setup all of these step-by-step in this guide in two main ways: * [Run with Docker Compose](/docs/nodes/block-results-producer-onboarding/run-brp-node/) (Recommended method - Beginner) * [Build & Run from Source](/docs/nodes/block-results-producer-onboarding/run-brp-node/) (Optional method - Advanced) ### Hardware Requirements The recommended configurations will make sure the sync is not lag prone and the node is able to keep up with the Ethereum network. #### Minimum * 2 vCPUs (cores) * 3GB RAM * 200GB HDD free storage (mostly storing artifacts on local ipfs; can be pruned periodically) * 8 MBit/sec download Internet service #### Recommended * 4 vCPUs * 8 GB+ RAM * SSD with >= 500GB storage space * 25+ MBit/sec download Internet service #### Software Requirements (Docker Setup) * 64-bit Linux, Mac OS 13+ * SSL certificates * docker, docker-compose, direnv # Run BRP Node Source: https://covalenthq.com/docs/nodes/block-results-producer-onboarding/run-brp-node As discussed in the setup section, there are two ways to setup the node and so accordingly these instructions are below: 1. **Run with Docker Compose** - (Recommended method - Beginner) 2. **Build & Run from Source** - (Optional method - Advanced) ### 1. Steps to Run Node with Docker: Note: The current **BRP-Refiner** stable version is **0.6.1**. For the latest updates or additional details, please check the announcements or discussions in **Discord**. Clone the [covalenthq/refiner](https://github.com/covalenthq/refiner/) repo. ```shell theme={null} git clone https://github.com/covalenthq/refiner cd refiner cat docker-compose-mbeam.yml ``` ```shell theme={null} $ cat .envrc export IPFS_PINNER_URL="http://ewm-das:5080/api/v1" export EVM_SERVER_URL="http://evm-server:3002" [[ -f .envrc.local ]] && source_env .envrc.local ``` ```shell theme={null} $ touch .envrc.local export BLOCK_RESULT_OPERATOR_PRIVATE_KEY="<>" export NODE_ETHEREUM_MAINNET="<>" export IPFS_PINNER_URL="http://ewm-das:5080/api/v1" export EVM_SERVER_URL="http://evm-server:3002" export W3_AGENT_KEY="<>" export W3_DELEGATION_FILE="<>" ``` **Note:** `.envrc.local` overrides any env vars set with `.envrc` on calling `direnv allow` . **Note:** When passing the private key into the env vars as above please remove the `0x` prefix so the private key env var has exactly 64 characters. * `BLOCK_RESULT_OPERATOR_PRIVATE_KEY:` Your personal Block Result Producer (BRP) operator private key * `AGENT_KEY & PROOF.OUT File:` Your personal web3.storage Agent key & Delegation file use by the `ipfs-pinner` service * `IPFS_PINNER_URL:` Service (`ipfs-pinner`) used by rudder to access IPFS assets like Block Specimens (service is automatically invoked and run with the in repo docker compose files eg: `docker-compose-mbeam.yml`) * `EVM_SERVER_URL:` Service (`evm-server`) used by rudder for stateless execution of Block Specimens into indexable (queryable) Block Results #### Start Services ```shell theme={null} $ direnv allow . #make sure you see these being loaded direnv: loading ~/refiner/.envrc direnv: loading ~/refiner/.envrc.local direnv: export +BLOCK_RESULT_OPERATOR_PRIVATE_KEY +EVM_SERVER_URL +IPFS_PINNER_URL +NODE_ETHEREUM_MAINNET +W3_AGENT_KEY +W3_DELEGATION_FILE ``` Copy over the delegation proof file to `~/.ipfs` repo. You should have gotten this from Covalent in addition to the `W3_AGENT_KEY` value. ```shell theme={null} mv path_to_delegation_file ~/.ipfs/proof.out ``` ```shell theme={null} $ docker compose -f "docker-compose-mbeam.yml" up -d --remove-orphans [+] Running 4/4 ⠿ Container refiner Started 3.2s ⠿ Container autoheal Started 0.5s ⠿ Container das-pinner Started 1.9s ⠿ Container evm-server Started 1.8s ``` NOTE: On a system where an `das-pinner` instance is already running, check the instruction in the [Appendix](https://www.covalenthq.com/docs/covalent-network/operator-onboarding-refiner/#appendix) to run `refiner` docker alongside. Monitor the logs for Block Result submissions. ```shell theme={null} $ docker compose -f "docker-compose-mbeam.yml" logs -f –tail 2 refiner | [info] curr_block: 4591264 and latest_block_num:4591263 das-pinner | 2023/06/22 13:45:49 Received /health request: source= 127.0.0.1:54420 status= OK refiner | [info] curr_block: 4591264 and latest_block_num:4591263 das-pinner | 2023/06/22 13:46:00 Received /health request: source= 127.0.0.1:54430 status= OK refiner | [info] curr_block: 4591264 and latest_block_num:4591264 refiner | [info] listening for events at 4591264 refiner | [info] found 0 bsps to process ``` **Check step 7 in Run BRP** from source section below for a successful Refiner stack run log output with performance metrics. #### Deployment As Service Unit: Here you can find an example of a `systemd` service unit file that can be used to auto-start/restart of the docker-compose service for Refiner. ```shell theme={null} [Unit] Description=Refiner docker compose PartOf=docker.service After=docker.service export IPFS_PINNER_URL="http://ewm-das:5080/api/v1" export EVM_SERVER_URL="http://evm-server:3002" [Service] User=blockchain Group=blockchain Environment=HOME=/home/blockchain/tmp Environment="BLOCK_RESULT_OPERATOR_PRIVATE_KEY=<>" Environment="NODE_ETHEREUM_MAINNET=<>" Environment="IPFS_PINNER_URL=http://ewm-das:5080/api/v1" #service in docker Environment="EVM_SERVER_URL=http://evm-server:3002" #service in docker Environment="W3_AGENT_KEY=<>" Environment="W3_DELEGATION_FILE=<>" Type=simple ExecStart=docker compose -f "/home/blockchain/tmp/docker-compose-mbeam.yml" up --remove-orphans Restart=always TimeoutStopSec=infinity [Install] WantedBy=multi-user.target ``` After adding the env vars in their respective fields in the service unit file, enable the service and start it. ```shell theme={null} sudo systemctl enable refiner-compose.service sudo systemctl start refiner-compose.service ``` **Note 1:** When passing the private key into the env vars as above please remove the 0x prefix so the private key env var has exactly 64 characters. **Note 2:** In order to run docker compose as a non-root user for the above shown service unit you need to create a docker group (if it doesn't exist) and add the user (say) "blockchain" to the docker group ```shell theme={null} sudo groupadd docker sudo usermod -aG docker blockchain sudo su - blockchain docker run hello-world ``` **Hurray!** You have Successfully implemented the BRP Node using Docker Compose #### 2. Steps to Run Node with Source: Here, to run the node from source we need to manually run all the three services step by step, follow this guide for implementing 1. EVM-Server 2. DAS-Pinner 3. Block Results Producer #### 1. Run EVM-Server The EVM-Server is a stateless EVM block execution tool. It's stateless because in Ethereum nodes like geth, it doesn't need to maintain database of blocks to do a block execution or re-execution. The `evm-server` service transforms Block Specimens to Block Results entirely on the input of underlying capture of Block Specimen data. Clone [covalenthq/erigon](https://github.com/covalenthq/erigon/) that contains the fork for this particular stateless execution function, Current stable version is `v1.3.2-evm`, build the `evm-server` binary ```shell theme={null} $ make evm ``` ```shell theme={null} $ ./build/bin/evm t8n --server.mode [INFO] [06-22|13:53:54.148] Listening port=3002 ``` **Note:** `evm-server` occupies the port 3002 on your local at `http://127.0.0.1:3002`", so make sure this port in not occupied by any other service prior to start. #### 2. Run DAS-Pinner DAS-Pinner serves as the interface to the storage layer of the network. It's a lightweight IPFS service that stores and pins data on the IPFS network using web3.storage. It is designed to work seamlessly with the DAS Light-Client, enabling the retrieval of data from the IPFS network and its verification using the DAS protocol.
It is meant for uploading/fetching network artifacts (like block specimens and block results or any other processed block data) files of the Covalent Decentralized Network. Clone [covalenthq/ewm-das](https://github.com/covalenthq/ewm-das/) and build the pinner server binary ```shell theme={null} $ git clone https://github.com/covalenthq/ewm-das.git $ cd ewm-das $ git checkout tags/v0.17.6 ## update if newer release is announced $ ./install-trusted-setup.sh $ make build-pinner ``` `ipfs-pinner` by getting `W3_AGENT_KEY` & `Proof.out` from web3.storage and adding it to an `.envrc` file. ```shell theme={null} $ cat .envrc export W3_AGENT_KEY="<>" export W3_DELEGATION_FILE="<>" ``` You should get the "w3 agent key" and "delegation proof file" from Covalent. After that, start the `ipfs-pinner` server. ```shell theme={null} ./bin/pinner -w3-agent-key $W3_AGENT_KEY -w3-delegation-file $W3_DELEGATION_FILE generating 2048-bit RSA keypair...done peer identity: QmZQSGUEVKQuCmChKqTBGdavEKGheCQgKgo2rQpPiQp7F8 Computing default go-libp2p Resource Manager limits based on: - 'Swarm.ResourceMgr.MaxMemory': "17 GB" - 'Swarm.ResourceMgr.MaxFileDescriptors': 61440 Applying any user-supplied overrides on top. Run 'ipfs swarm limit all' to see the resulting limits. 2023/04/20 12:47:49 Listening... ``` Note: das-pinner occupies the port 5080 on your local at [http://127.0.0.1:5080/api/v1](http://127.0.0.1:5080/api/v1), so make sure this port in not occupied by any other service prior to start. #### Debugging: Repo Migrations In case of the following error ```shell theme={null} 2023-03-10T08:46:18.621-0800 FATAL ipfs-pinner ipfs-pinner/pinner.go:29 error initializing ipfs node: ipfs repo needs migration, please run migration tool. See https://github.com/ipfs/fs-repo-migrations/blob/master/run.md Sorry for the inconvenience. In the future, these will run automatically. ``` Run the following migrations ```shell theme={null} wget https://dist.ipfs.tech/fs-repo-migrations/v2.0.2/fs-repo-migrations_v2.0.2_darwin-arm64.tar.gz tar -xvf fs-repo-migrations_v2.0.2_darwin-arm64.tar.gz cd fs-repo-migrations/ ./fs-repo-migrations ``` #### 3. Run Block Results Producer (BRP): BRP is the primary orchestrator and supervisor for all transformation pipeline processes that locates a source Covalent Network data object to apply a tracing/execution/transformational rule to and outputs a new object generated from using such a rule. Both the source and output are available through a decentralized storage service such as a wrapped IPFS node. A transformation-proof transaction is emitted, confirming that it has done this work along with the output content ids (ipfs) access URL. To define what these three components are: **Source:** The Block Specimen that serves as an input to the Refiner. Proof transactions made earlier to a smart contract with the respective cids (content ids) are where the source is checked. **Rule:** A transformation plugin (or server) that can act on the Block Specimen (source). These can be compared to blueprints that have been shown to produce the data objects needed. Furthermore, anyone can create these rules to get a desired data object. Rule (or server) versions thus need to exist, tied to the decoded block specimen versions they are applied on. **Target:** The output generated from running the rule over the object that came from the source that is the block result. #### Steps to Run BRP: Clone the `refiner` repo ```shell theme={null} git clone https://github.com/covalenthq/refiner.git cd refiner git checkout tags/v0.6.1 ``` Get your `BLOCK_RESULT_OPERATOR_PRIVATE_KEY` that has `GLMR` tokens for Moonbeam and is already whitelisted as Block Result Producer operator. Set the following environment variables for the local refiner by creating an `.envrc.local` file * Copy paste the environment variables into this file ```shell​ theme={null} touch .envrc.local export BLOCK_RESULT_OPERATOR_PRIVATE_KEY="BRP-OPERATOR-PK-WITHOUT-0x-PREFIX" export NODE_ETHEREUM_MAINNET="<>" export IPFS_PINNER_URL="http://127.0.0.1:5080/api/v1" export EVM_SERVER_URL="http://127.0.0.1:3002" ``` Call to load `.envrc.local + .envrc` files with the command below and observe the following output, make sure the environment variables are loaded into the shell.
* Once the env vars are passed into the `.envrc.local` file and loaded in the shell with `direnv allow .`, build the `refiner` application for the `prod` env i.e moonbeam mainnet or `dev` env for moonbase alpha as discussed before. ```shell theme={null} $ direnv allow . #make sure you see these being loaded direnv: loading ~/refiner/.envrc direnv: loading ~/refiner/.envrc.local direnv: export +BLOCK_RESULT_OPERATOR_PRIVATE_KEY +EVM_SERVER_URL +IPFS_PINNER_URL +NODE_ETHEREUM_MAINNET +W3_AGENT_KEY +W3_DELEGATION_FILE ``` Get all the required dependencies and build the `refiner` app. ```shell theme={null} mix local.hex --force && mix local.rebar --force && mix deps.get ``` * For moonbeam mainnet. * For moonbase alpha. ```shell theme={null} #moonbeam-mainnet MIX_ENV=prod mix release ​ #moonbase-alpha MIX_ENV=dev mix release ​ . .. .... evm-server: http://127.0.0.1:3002 ipfs-node: http://127.0.0.1:5080/api/v1 * assembling refiner-0.2.12 on MIX_ENV=dev * skipping runtime configuration (config/runtime.exs not found) * skipping elixir.bat for windows (bin/elixir.bat not found in the Elixir installation) * skipping iex.bat for windows (bin/iex.bat not found in the Elixir installation) Release created at _build/dev/rel/refiner    # To start your system    _build/dev/rel/refiner/bin/refiner start Once the release is running:    # To connect to it remotely    _build/dev/rel/refiner/bin/refiner remote    # To stop it gracefully (you may also send SIGINT/SIGTERM)    _build/dev/rel/refiner/bin/refiner stop To list all commands:   _build/dev/rel/refiner/bin/refiner ``` Start the `refiner` application and execute the proof-chain block specimen listener call which should run the Refiner pipeline pulling Block Specimens from IPFS using the cids read from recent proof-chain finalized transactions, decoding them, and uploading and proofing Block Results while keeping a track of failed ones and continuing (soft real-time) in case of failure. The erlang concurrent fault tolerance allows each pipeline to be an independent worker that can fail (for any given Block Specimen) without crashing the entire pipeline application. Multiple pipeline worker children threads continue their work in the synchronous queue of Block Specimen AVRO binary files running the stateless EVM binary (`evm-server`) re-execution tool. ```shell theme={null} #moonbeam-mainnet MIX_ENV=prod mix run --no-halt --eval 'Refiner.ProofChain.BlockSpecimenEventListener.start()'; ​ #moonbase-alpha MIX_ENV=dev mix run --no-halt --eval 'Refiner.ProofChain.BlockSpecimenEventListener.start()'; ​ ​ .. ... refiner       | [info] found 1 bsps to process ipfs-pinner | 2023/06/29 20:28:30 unixfsApi.Get: getting the cid: bafybeiaxl44nbafdmydaojz7krve6lcggvtysk6r3jaotrdhib3wpdb3di ipfs-pinner | 2023/06/29 20:28:30 trying out https://w3s.link/ipfs/bafybeiaxl44nbafdmydaojz7krve6lcggvtysk6r3jaotrdhib3wpdb3di ipfs-pinner | 2023/06/29 20:28:31 got the content! refiner       | [info] Counter for ipfs_metrics - [fetch: 1] refiner       | [info] LastValue for ipfs_metrics - [fetch_last_exec_time: 0.001604] refiner       | [info] Sum for ipfs_metrics - [fetch_total_exec_time: 0.001604] refiner       | [info] Summary for ipfs_metrics - {0.001604, 0.001604} refiner       | [debug] reading schema `block-ethereum` from the file /app/priv/schemas/block-ethereum.avsc refiner       | [info] Counter for bsp_metrics - [decode: 1] refiner       | [info] LastValue for bsp_metrics - [decode_last_exec_time: 0.0] refiner       | [info] Sum for bsp_metrics - [decode_total_exec_time: 0.0] refiner       | [info] Summary for bsp_metrics - {0.0, 0.0} refiner       | [info] submitting 17586995 to evm http server... evm-server   | [INFO] [06-29|20:28:31.859] input file at                           loc=/tmp/3082854681 evm-server   | [INFO] [06-29|20:28:31.862] output file at:                         loc=/tmp/1454174090 evm-server   | [INFO] [06-29|20:28:32.112] Wrote file                               file=/tmp/1454174090 refiner       | [info] writing block result into "/tmp/briefly-1688/briefly-576460747542186916-YRw0mRjfExGMk4M672" refiner       | [info] Counter for bsp_metrics - [execute: 1] refiner       | [info] LastValue for bsp_metrics - [execute_last_exec_time: 3.14e-4] refiner       | [info] Sum for bsp_metrics - [execute_total_exec_time: 3.14e-4] refiner       | [info] Summary for bsp_metrics - {3.14e-4, 3.14e-4} ipfs-pinner | 2023/06/29 20:28:32 generated dag has root cid: bafybeic6ernzbb6x4qslwfgklveisyz4vkuqhaafqzwlvto6c2njonxi3e ipfs-pinner | 2023/06/29 20:28:32 car file location: /tmp/249116437.car [119B blob data] ipfs-pinner | 2023/06/29 20:28:34 Received /health request: source= 127.0.0.1:34980 status= OK ipfs-pinner | 2023/06/29 20:28:34 uploaded file has root cid: bafybeic6ernzbb6x4qslwfgklveisyz4vkuqhaafqzwlvto6c2njonxi3e refiner       | [info] Counter for ipfs_metrics - [pin: 1] refiner       | [info] LastValue for ipfs_metrics - [pin_last_exec_time: 0.002728] refiner       | [info] Sum for ipfs_metrics - [pin_total_exec_time: 0.002728] refiner       | [info] Summary for ipfs_metrics - {0.002728, 0.002728} refiner       | [info] 17586995:48f1e992d1ac800baed282e12ef4f2200820061b5b8f01ca0a9ed9a7d6b5ddb3 has been successfully uploaded at ipfs://bafybeic6ernzbb6x4qslwfgklveisyz4vkuqhaafqzwlvto6c2njonxi3e refiner       | [info] 17586995:48f1e992d1ac800baed282e12ef4f2200820061b5b8f01ca0a9ed9a7d6b5ddb3 proof submitting refiner       | [info] Counter for brp_metrics - [proof: 1] refiner       | [info] LastValue for brp_metrics - [proof_last_exec_time: 3.6399999999999996e-4] refiner       | [info] Sum for brp_metrics - [proof_total_exec_time: 3.6399999999999996e-4] refiner       | [info] Summary for brp_metrics - {3.6399999999999996e-4, 3.6399999999999996e-4} refiner       | [info] 17586995 txid is 0xd8a8ea410240bb0324433bc26fdc79d496ad0c8bfd18b60314a05e3a0de4fb06 refiner       | [info] Counter for brp_metrics - [upload_success: 1] refiner       | [info] LastValue for brp_metrics - [upload_success_last_exec_time: 0.0031149999999999997] refiner       | [info] Sum for brp_metrics - [upload_success_total_exec_time: 0.0031149999999999997] refiner       | [info] Summary for brp_metrics - {0.0031149999999999997, 0.0031149999999999997} refiner       | [info] Counter for refiner_metrics - [pipeline_success: 1] refiner       | [info] LastValue for refiner_metrics - [pipeline_success_last_exec_time: 0.0052] ``` Check logs for any errors in the pipeline process and note the performance metrics in line with execution. Checkout the documentation on what is being measured and why [here](https://github.com/covalenthq/refiner/blob/main/docs/METRICS.md/). ```shell theme={null} tail -f logs/log.log .. ... refiner       | [info] Counter for refiner_metrics - [pipeline_success: 1] refiner       | [info] LastValue for refiner_metrics - [pipeline_success_last_exec_time: 0.0052] refiner       | [info] Sum for refiner_metrics - [pipeline_success_total_exec_time: 0.0052] refiner       | [info] Summary for refiner_metrics - {0.0052, 0.0052} ``` Alternatively - check proof-chain logs for correct block result proof submissions and transactions made by your block result producer. [For moonbeam](https://moonscan.io/address/0x4932bDc983e5146224b9C2e68cfFBFEb004A2824). [For moonbase](https://moonbase.moonscan.io/address/0xCBC44F143FB5baf26e45FB6C7A4fC13e6ca0fa09). **Note:** For any issues associated with building and re-compiling execute the following commands, that cleans, downloads and re-compiles the dependencies for refiner. ```shell theme={null} rm -rf _build deps && mix clean && mix deps.get && mix deps.compile ``` If you got everything working so far. Congratulations! You're now a Refiner operator on the CXT Network. Set up Grafana monitoring and alerting from links in the [additional resources](https://github.com/covalenthq/refiner#additional-resources) section. #### Troubleshooting To avoid permission errors with `~/.ipfs` folder execute the following in your home directory. ```shell theme={null} sudo chmod -R 770 ~/.ipfs ``` To avoid netscan issue execute the following against ipfs binary application. ```shell theme={null} sudo chmod -R 700 ~/.ipfs ipfs config profile apply server ``` To avoid issues with ipfs-pinner v1.1.0, a small repo migration for the local `~/.ipfs` directory may be needed from - [here](https://github.com/ipfs/fs-repo-migrations/blob/master/run.md). For linux systems follow the below steps. ```shell theme={null} wget https://dist.ipfs.tech/fs-repo-migrations/v2.0.2/fs-repo-migrations_v2.0.2_linux-amd64.tar.gz tar -xvf fs-repo-migrations_v2.0.2_linux-amd64.tar.gz cd fs-repo-migrations chmod +x ./fs-repo-migrations ./fs-repo-migrations ``` #### Bugs Reporting Contributions Please follow the guide in docs [contribution guidelines](https://github.com/covalenthq/refiner/blob/main/docs/CONTRIBUTING.md) for bug reporting and contributions. #### Scripts In order to run the Refiner docker compose services as a service unit. The example service unit file in [docs](https://github.com/covalenthq/refiner/blob/main/docs/refiner-compose.service) should suffice. After adding the env vars in their respective fields in the service unit file, enable the service and start it. ```shell theme={null} sudo systemctl enable refiner-compose.service sudo systemctl start refiner-compose.service ``` **Note::** To run docker compose as a non-root user for the above shown service unit, you need to create a docker group (if it doesn't exist) and add the user “blockchain” to the docker group. ```shell theme={null} sudo groupadd docker sudo usermod -aG docker blockchain sudo su - blockchain docker run hello-world ``` #### Appendix #### Run With Existing IPFS-Pinner Service On a system where an `ipfs-pinner` instance is already running, use this modified `.envrc.local` and `docker-compose-mbeam.yml` ```shell theme={null} export BLOCK_RESULT_OPERATOR_PRIVATE_KEY="BRP-OPERATOR-PK-WITHOUT-0x-PREFIX" export NODE_ETHEREUM_MAINNET="<>" export IPFS_PINNER_URL="http://host.docker.internal:5080/api/v1" export EVM_SERVER_URL="http://evm-server:3002" ``` **Note:** When passing the private key into the env vars as above please remove the `0x` prefix so the private key env var has exactly 64 characters. ```shell theme={null} version: '3' # runs the entire refiner pipeline with all supporting services (including refiner) in docker # set .env such that all services in docker are talking to each other only; ipfs-pinnern is assumed # to be hosted on the host machine. It's accessed through http://host.docker.internal:5080//api/v1 url from # inside refiner docker container. services: evm-server: image: "us-docker.pkg.dev/covalent-project/network/evm-server:stable" container_name: evm-server restart: always labels: "autoheal": "true" expose: - "3002:3002" networks: - cxt-net ports: - "3002:3002" refiner: image: "us-docker.pkg.dev/covalent-project/network/refiner:stable" container_name: refiner links: - "ewm-das:ewm-das" - "evm-server:evm-server" # build: # context: . # dockerfile: Dockerfile restart: always depends_on: ewm-das: condition: service_healthy evm-server: condition: service_healthy entrypoint: > /bin/bash -l -c " echo "moonbeam-node:" $NODE_ETHEREUM_MAINNET; echo "evm-server:" $EVM_SERVER_URL; echo "ewm-das:" $IPFS_PINNER_URL; cd /mix; MIX_ENV=prod mix deps.get; MIX_ENV=prod mix release --overwrite; MIX_ENV=prod mix run --no-halt --eval 'Refiner.ProofChain.BlockSpecimenEventListener.start()';" environment: - NODE_ETHEREUM_MAINNET=${NODE_ETHEREUM_MAINNET} - BLOCK_RESULT_OPERATOR_PRIVATE_KEY=${BLOCK_RESULT_OPERATOR_PRIVATE_KEY} - EVM_SERVER_URL=${EVM_SERVER_URL} - IPFS_PINNER_URL=${IPFS_PINNER_URL} networks: - cxt-net ports: - "9568:9568" autoheal: image: willfarrell/autoheal container_name: autoheal volumes: - "/var/run/docker.sock:/var/run/docker.sock" environment: - AUTOHEAL_INTERVAL=10 - CURL_TIMEOUT=30 networks: cxt-net: ``` and start the `refiner` and `evm-server` services: ```shell theme={null} $ docker compose -f "docker-compose-mbeam.yml" up --remove-orphans [+] Running 3/3 ⠿ Network refiner_cqt-net Created 0.0s ⠿ Container evm-server Started 0.7s ⠿ Container refiner Started 1.5s ``` # Setup BRP Node Source: https://covalenthq.com/docs/nodes/block-results-producer-onboarding/setup ### Prerequisites for Validator & Operator nodes 1. **Staking Address:** This is the address of the wallet holding your CXT on Ethereum mainnet. 2. **Operator Address:** This is a public address tied to the private-public key pair an operator will use to sign proof transactions to the proof-chain contract on moonbeam. * Please provide the public address to this pair to Covalent. Keep the private key secret and safe. **Please make sure that the Staking address and Operator Address are separate**. ```shell theme={null} It can be generated using the BIP-44 mnemonic multi-account deterministic algorithm. It can be generated using https://iancoleman.io/bip39/ (select 24 words, Coin: ETH). ``` Min 35,000 CXT & Max 70,000 CXT on Ethereum mainnet. **In order to send proofs of block specimens.** This costs approximately 5 GLMR per day. This should be held at the same address as the Operator Address. Import your Validator private key into Metamask, select the Ethereum mainnet network and connect your **Staking wallet** to the [operator dashboard](https://www.covalenthq.com/staking/#/operator-dashboard/).Your operator should be currently disabled. Self-Stake the Minimum CXT Staking requirement on Ethereum (35,000 CXT) for BRP. This is done using the **Change Stake** button in your [operator dashboard](https://www.covalenthq.com/staking/#/operator-dashboard/). Proceed to first set Stake Amount to 35000 and click **Approve**. After the on chain approval transaction completes, click on **Stake**. Once the staking transaction completes, your Staking Status should display **Sufficiently Staked** and **Enabled**. Get access to a reliable Moonbeam https RPC. Providers and RPC URLs can be found [here](https://docs.moonbeam.network/builders/get-started/endpoints/#endpoint-providers) . Ping the Covalent team on discord for recommendations. Validators can create a [web3.storage](https://web3.storage/) account and have `did key`, `W3-agent-key` and `proof.out` for `das-pinner` file or can reach out to covalent team on discord for these details. ### Install Dependencies: As we discussed in previous section, We can setup the nodes two ways so here in this section, you can follow dependencies accordingly: * **Run with Docker Compose** (Recommended method - Beginner) * **Build & Run from Source** (Optional method - Advanced) ### Dependencies to Run with Docker Compose: 1. Install Docker Follow the [docker install instructions](https://docs.docker.com/engine/install) for your platform/architecture. Onboarding instructions will be [based on Ubuntu 22.04 LTS x86\_64 / amd64](https://docs.docker.com/engine/install/ubuntu/) 2. Install `direnv` #### Debian/Ubuntu ```shell bash theme={null} sudo apt update sudo apt get direnv # bash users - add the following line to your ~/.bashrc eval "$(direnv hook bash)" source ~/.bashrc ``` ```shell zsh theme={null} sudo apt update sudo apt get direnv # zsh users - add the following line to your ~/.zshrc eval "$(direnv hook zsh)" source ~/.zshrc ``` #### MacOS 12.x (M1/Intel) ```shell theme={null} brew install direnv ``` ### Dependencies to Run with Source: #### Prerequisites **MacOS 12.x (M1/Intel) Installation requirements** Install XCode (skip if you already have xcode and have been developing on your mac) ```shell theme={null} xcode-select --install sudo xcodebuild -license agree ``` You must also Install brew (for mac m1/intel) with this [script](https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh). This installs all the minimum necessary terminal/command-line tools to get started with easy software development on a mac. **Installation Time:** 35-40 mins depending on your machine and network. Install `git`, `go`, `asdf`, `erlang`, `elixir`, `direnv`, `go-ipfs` * Git is used as the source code version control manager across all our repositories. * Go is the programming language that is used to develop on go-ethereum, bsp-agent, erigon (EVM plugin) all which are entirely written in go. * Asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. * Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. * Elixir is a programming language that runs on the Erlang VM, known for creating low-latency, distributed, high concurrency fault-tolerant systems. * IPFS as the InterPlanetary File System (IPFS) is a protocol, hypermedia and file sharing peer-to-peer network for storing and sharing data in a distributed file system. * Direnv is used for secret management and control. Since all the necessary parameters to the agent that are sensitive cannot be passed into a command line flag. Direnv allows for safe and easy management of secrets like ethereum private keys for the operator accounts on the Covalent Network and redis instance access passwords etc. As these applications are exposed to the internet on http ports it’s essential to not have the information be logged anywhere. To enable “direnv” on your machine add these to your \~./bash\_profile or \~./zshrc depending on which you use as your default shell after installing it using brew. Here, are the commands that can be used to install the dependencies select based on your OS accordingly #### MacOS 12.x (M1/Intel) Install dependencies ```shell theme={null} /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" brew install coreutils curl git wget direnv asdf ``` For setting up asdf on other shells please refer to [this guide.](https://asdf-vm.com/guide/getting-started.html) #### Linux x86\_64 (Ubuntu 22.04 LTS) Install dependencies ```shell theme={null} sudo apt update sudo apt install build-essential coreutils libssl-dev automake autoconf libncurses5-dev curl git wget direnv unzip git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.11.2 echo ". $HOME/.asdf/asdf.sh" >> ~/.bashrc echo ". $HOME/.asdf/completions/asdf.bash" >> ~/.bashrc source ~/.bashrc ``` ```shell theme={null} asdf plugin add erlang https://github.com/asdf-vm/asdf-erlang.git asdf plugin add elixir https://github.com/asdf-vm/asdf-elixir.git asdf plugin add golang https://github.com/kennyp/asdf-golang.git ``` Add to your bash shell for asdf for any other shell, check [the asdf guide.](https://asdf-vm.com/guide/getting-started.html) ```shell theme={null} echo -e "\n. \"$(brew --prefix asdf)/etc/bash_completion.d/asdf.bash\"" >> ~/.bash_profile ``` ```shell theme={null} asdf install erlang 25.3 asdf install elixir 1.14.3-otp-24 asdf install golang 1.22.5 ``` This will create a  `.tool-versions`
  file in your home directory. ASDF will use these versions whenever a project doesn't specify versions of its own. ```shell theme={null} asdf global erlang 25.3 asdf global elixir 1.14.3-otp-24 asdf global golang 1.22.5 ``` ```shell bash theme={null} #bash users - add the following line to your ~/.bashrc eval "$(direnv hook bash)" ``` ```shell zsh theme={null} #zsh users - add the following line to your ~/.zshrc eval "$(direnv hook zsh)" ``` After adding this line do not forget to source your bash / powershell config with the following, by running it in your terminal ```shell bash theme={null} source ~/.bashrc ``` ```shell zsh theme={null} source ~/.zshrc ``` **MacOS 12.x (M1/Intel)** ```shell theme={null} wget https://dist.ipfs.tech/go-ipfs/v0.18.0/go-ipfs_v0.18.0_darwin-arm64.tar.gz tar -xzvf go-ipfs_v0.18.0_darwin-arm64.tar.gz cd go-ipfs bash install.sh ipfs init ``` ```shell theme={null} wget https://dist.ipfs.tech/go-ipfs/v0.18.0/go-ipfs_v0.18.0_linux-amd64.tar.gz tar -xzvf go-ipfs_v0.18.0_darwin-arm64.tar.gz cd go-ipfs bash install.sh ipfs init ``` **Note:** To avoid permissions and netscan issues execute the following against ipfs binary home directory application ```shell theme={null} sudo chmod -R 700 ~/.ipfs ipfs config profile apply server ``` # Block Specimen Producer Onboarding Source: https://covalenthq.com/docs/nodes/block-specimen-producer-onboarding/bsp-onboarding-home Running a block specimen producer node is very input/output (I/O) intensive. Here, the requirements to run a BSP node match that of running `go-ethereum` full node with some additional provisions discussed below. ### Hardware Requirements The recommended configurations will make sure the sync is not lag-prone and the node is able to keep up with the Ethereum network. #### Minimum Requirements: * CPU with 4+ cores * 16GB RAM * 1.5TB free storage space to sync the Ethereum Mainnet * 8 MBit/sec download Internet service #### Recommended: * Fast CPU with 8+ cores * 32 GB+ RAM * Fast SSD with >= 1.5TB storage space * 25+ MBit/sec download Internet service ### Software Requirements Install the given versions of the following software: * 64-bit Linux, Mac OS * SSL certificates * Git * BSP-geth v1.8.0-bsp ships with - Geth v1.13.14-stable * Go v1.20 * Redis v7, Redis-cli 7.\* * Listener TCP and UDP discovery port 30303 * ICMP IPv4 should not be closed by an external firewall # Run BSP Node Source: https://covalenthq.com/docs/nodes/block-specimen-producer-onboarding/run-bsp-node #### Run & Build BSP Agent from Source Next, we’re going to install the agent that can transform the specimens to AVRO encoded blocks, prove that their data contains what is encoded and upload them to an object store.
Clone the [covalenthq/bsp-agent](https://github.com/covalenthq/bsp-agent) repo in a separate terminal and build. Note: The current **bsp-agent** stable version is **v1.9.2**. For the latest updates or additional details, please check the announcements or discussions in **Discord**. ```shell theme={null} git clone https://github.com/covalenthq/bsp-agent.git cd bsp-agent make build ``` * Add a `.envrc` file to `~/bsp-agent` and add the private key to your operator account address. (See below on how to do this for this workshop) * Here we set up the required env vars for the bsp-agent. Other variables that are not secrets are passed as flags. Add the entire line below to the .envrc file with the replaced keys, rpc url and ipfs service token, and save the file. ```shell theme={null} cd bsp-agent touch .envrc export MB_RPC_URL=** moonbeam RPC url ** export MB_PRIVATE_KEY=** Your BSP Operator private key ** ``` allow direnv to catch the exported constant and enable it with the direnv allow command. ```shell theme={null} direnv allow ``` NOTE: You should see something like this if the env variables have been correctly exported and ready to use. If you don’t see this prompt in the terminal please enable/install direnv using the instructions on install dependencies page of this guide. ```shell theme={null} direnv: loading ~/Documents/covalent/bsp-agent/.envrc direnv: export +MB_PRIVATE_KEY +MB_RPC_URL ``` Make sure that you replace \$PROOF\_CHAIN\_CONTRACT\_ADDR with the new copied “proof-chain” contract address in the command below for the `--proof-chain-address` flag and create a bin directory at `~/bsp-agent` to store the block-specimens binary files with NOTE: Moonbeam Proof-Chain Address: `0x7487b04899c2572A223A8c6eC9bA919e27BBCd36` Assuming the das-pinner is running (last section) at the default `http://127.0.0.1:5080/api/v1`, we can now start the `bsp-agent`:
Each of the agent’s flags and their functions are described below (some may have been taken out for simplifying this workshop)
`--redis-url` - this flag tells the agent where to find the bsp messages, at which stream topic key (replication) and what the consumer group is named with the field after # which in this case is replicate, additionally one can provide a password to the redis instance here but we recommend by adding the line below to the .envrc
`export REDIS_PWD=your-redis-pwd`
`--codec-path` - tells the bsp agent the relative path to the AVRO .avsc files in the repo, since the agent ships with the corresponding avsc files this remains fixed for the time being
`--binary-file-path` - tells the bsp if local copies of the block-replica objects being created are to be stored in a given local directory. Please make sure the path (& directory) pre-exists before passing this flag.
`--block-divisor` - allows the operator to configure the number of block specimens being created, the block number divisible only by this number will be extracted, packed, encoded, uploaded and proofed.
`--proof-chain-address` - specifies the address of the proof-chain contract that has been deployed to the Moonbeam network.
`--consumer-timeout` - specifies when the agent stops accepting new msgs from the pending queue for encode, proof and upload.
`--log-folder` - specifies the location (folder) where the log files have to be placed. In case of error (like permission errors), the logs are not recorded in files.
`--ipfs-pinner-server` - specifies the http url where ipfs-pinner server is listening. By default, it is `http://127.0.0.1:5080/api/v1`
NOTE: if the `bsp-agent` command above fails with a message about permission issues to access `~/.ipfs/*`, run `sudo chmod -R 700 ~/.ipfs` and try again. Sample Service systemmd file for [bsp-agent](https://www.covalenthq.com/docs/nodes/block-specimen-producer-onboarding/run-bsp-node#bsp-agent-service-unit-file) can be found here. ```shell theme={null} $ cd ../bsp-agent $ ./bin/bspagent \ --redis-url="redis://username:@localhost:6379/0?topic=replication" \ --avro-codec-path="./codec/block-ethereum.avsc" \ --binary-file-path="./bin/block-ethereum" \ --block-divisor=35 \ --proof-chain-address=0x7487b04899c2572A223A8c6eC9bA919e27BBCd36 \ --consumer-timeout=10000000 \ --log-folder ./logs/ \ --ipfs-pinner-server "http://127.0.0.1:5080/api/v1" ``` If all the cli-flags are administered correctly (either in the makefile or the go run command) you should be able to see something like this from logs ```shell theme={null} time="2022-04-18T17:26:47Z" level=info msg="Initializing Consumer: fb78bb1c-1e14-4905-bb1f-0ea96de8d8b5 | Redis Stream: replication-1 | Consumer Group: replicate-1" function=main line=167 time="2022-04-18T17:26:47Z" level=info msg="block-specimen not created for: 10430548, base block number divisor is :3" function=processStream line=332 time="2022-04-18T17:26:47Z" level=info msg="stream ids acked and trimmed: [1648848491276-0], for stream key: replication-1, with current length: 11700" function=processStream line=339 time="2022-04-18T17:26:47Z" level=info msg="block-specimen not created for: 10430549, base block number divisor is :3" function=processStream line=332 time="2022-04-18T17:26:47Z" level=info msg="stream ids acked and trimmed: [1648848505274-0], for stream key: replication-1, with current length: 11699" function=processStream line=339 ---> Processing 4-10430550-replica <--- time="2022-04-18T17:26:47Z" level=info msg="Submitting block-replica segment proof for: 4-10430550-replica" function=EncodeProveAndUploadReplicaSegment line=59 time="2022-04-18T17:26:47Z" level=info msg="binary file should be available: ipfs://QmUQ4XYJv9syrokUfUbhvA4bV8ce7w1Q2dF6NoNDfSDqxc" function=EncodeProveAndUploadReplicaSegment line=80 time="2022-04-18T17:27:04Z" level=info msg="Proof-chain tx hash: 0xcc8c487a5db0fec423de62f7ac4ca81c630544aa67c432131cabfa35d9703f37 for block-replica segment: 4-10430550-replica" function=EncodeProveAndUploadReplicaSegment line=86 time="2022-04-18T17:27:04Z" level=info msg="File written successfully to: /scratch/node/block-ethereum/4-10430550-replica-0xcc8c487a5db0fec423de62f7ac4ca81c630544aa67c432131cabfa35d9703f37" function=writeToBinFile line=188 time="2022-04-18T17:27:04Z" level=info msg="car file location: /tmp/28077399.car\n" function=generateCarFile line=133 time="2022-04-18T17:27:08Z" level=info msg="File /tmp/28077399.car successfully uploaded to IPFS with pin: QmUQ4XYJv9syrokUfUbhvA4bV8ce7w1Q2dF6NoNDfSDqxc" function=HandleObjectUploadToIPFS line=102 time="2022-04-18T17:27:08Z" level=info msg="stream ids acked and trimmed: [1648848521276-0], for stream key: replication-1, with current length: 11698" function=processStream line=323 ``` If you see the above log, you’re successfully running the entire block specimen producer workflow. The BSP-agent is reading messages from the redis streams topic, encoding, compressing, proving and uploading it to the gcp bucket in segments of multiple blocks at a time.
If however, that doesn’t happen and the agent fails and isn’t able to complete the workflow, fear not! It will automatically fail and the messages will be persisted in the stream where they were being read from! So when you restart correctly the same messages will be reprocessed till full success.
Please note any ERR / WARN / DEBUG messages that could be responsible for the failure. The messages should be clear enough to pinpoint the exact issue. Additionally, get support from Covalent's discord community! ### Sample Systemd Service Units If the block specimen stack is running successfully and producing block specimens, Congrats! As a way to manage the services, you might want to use systemd.
We next provide sample systemd service files, so that any crash in one of the components would restart that component, rather than the system halting. Don't forget to replace the placeholders with actual values in these sample files. #### BSP-Geth - Service Unit File ```shell theme={null} [Unit] Description=Bsp Geth service Wants=network-online.target After=network.target [Service] User=ubuntu Group=ubuntu Type=simple WorkingDirectory=/home/ubuntu/covalent/bsp-geth/ ExecStart=./build/bin/geth --mainnet --log.debug --syncmode snap --datadir $PATH_TO_GETH_MAINNET_CHAINDATA --replication.targets "redis://localhost:6379/?topic=replication" --replica.result --replica.specimen --replica.blob --log.folder "./logs/" Restart=always [Install] WantedBy=multi-user.target ``` #### Lighthouse - Service Unit File ```shell theme={null} [Unit] Description=lighthouse service Wants=network-online.target After=network.target [Service] User=ubuntu Group=ubuntu Type=simple WorkingDirectory=/home/ubuntu/covalent/lighthouse/ ExecStart=./build/bin/lighthouse bn --network mainnet --execution-endpoint http://localhost:8551 --execution-jwt /Users//repos/experiment/bsp_doc/bsp-geth/data/geth/jwtsecret --checkpoint-sync-url https://mainnet.checkpoint.sigp.io --disable-deposit-contract-sync Restart=always [Install] WantedBy=multi-user.target ``` #### DAS-Pinner - Service Unit File ```shell theme={null} [Unit] Description=Bsp Agent service Wants=network-online.target [Unit] Description=das-pinner client After=syslog.target network.target [Service] User=ubuntu Group=ubuntu Environment="W3_AGENT_KEY=<>", "W3_DELEGATION_FILE=<>" Type=simple ExecStart=/opt/ewm-das/bin/pinner Restart=always TimeoutStopSec=infinity [Install] WantedBy=multi-user.target ``` #### BSP-Agent - Service Unit File ```shell theme={null} [Unit] Description=Bsp Agent service Wants=network-online.target After=network.target [Service] User=ubuntu Group=ubuntu Type=simple WorkingDirectory=/home/ubuntu/covalent/bsp-agent/ ExecStart=./bin/bspagent --redis-url="redis://username:@localhost:6379/0?topic=replication" --avro-codec-path="/home/ubuntu/covalent/bsp-agent/codec/block-ethereum.avsc" --binary-file-path="/home/ubuntu/covalent/bsp-agent/data/bin/block-ethereum" --block-divisor=35 --proof-chain-address=0x7487b04899c2572A223A8c6eC9bA919e27BBCd36 --consumer-timeout=10000000 --log-folder /home/ubuntu/covalent/bsp-agent/logs/ --ipfs-pinner-server=http://127.0.0.1:5080/api/v1 Restart=always [Install] WantedBy=multi-user.target ``` ### Support If you need any assistance with the onboarding process or have technical and operational concerns please contact Rodrigo or Krish in the [Covalent Network Discord](https://discord.gg/VHgmzB9973). # Setup BSP Node Source: https://covalenthq.com/docs/nodes/block-specimen-producer-onboarding/setup ### Prerequisites for Operator nodes Before you get started, make sure you have: * the minimum self-stake CXT available, currently 175K CXT * your operator address is added and enabled on the [operator dashboard](https://www.covalenthq.com/staking/#/operator-dashboard) Glimmer (GLMR) is needed to pay for gas on Moonbeam in order to send proofs of block specimens and block results. This process currently costs *5 GLMR* per day. The balance should be held at the same address as the operator address. ## Install Dependencies ### MacOS 12.x (M1/Intel) Installation requirements #### Install XCode * You must also Install brew (for mac m1/intel) This installs all the minimum necessary terminal/command-line tools to get started with software development on a mac. **Complete Installation Time: 1-1.5 hrs** depending on your machine and network. Install `Git`, `Golang`, `Redis`. * `Git` is used as the source code version control manager across all our repositories. * `Go` is the programming language that is used to develop on `go-ethereum` and bsp patches, the agent given below is also entirely written in Go. * `Redis` is our in-memory database, cache and streaming service provider. Installation steps are given for various types of OS follow the one suits best for you. Current `Go Version: Go 1.22 or later` #### MacOS 12.x (M1/Intel) ```shell theme={null} brew install git go redis ``` #### Debian/Ubuntu ```shell theme={null} wget https://golang.org/dl/go1.22.5.linux-amd64.tar.gz tar -xvf go1.22.5.linux-amd64.tar.gz sudo mv go /usr/local echo "" >> ~/.bashrc echo 'export GOPATH=$HOME/go' >> ~/.bashrc echo 'export GOROOT=/usr/local/go' >> ~/.bashrc echo 'export GOBIN=$GOPATH/bin' >> ~/.bashrc echo 'export PATH=$PATH:/usr/local/go/bin:$GOBIN' >> ~/.bashrc echo 'export GO111MODULE=on' >> ~/.bashrc source .bashrc # install redis and git apt install git redis-server ``` #### Fedora ```shell theme={null} dnf install git golang redis ``` #### RHEL/CentOS Install Git, Golang, Redis ```shell theme={null} yum install git go-toolset redis ``` #### OpenSUSE/SLES Install Git, Golang, Redis ```shell theme={null} zypper addrepo https://download.opensuse.org/repositories/devel:languages:go/openSUSE_Leap_15.3/devel:languages:go.repo zypper refresh zypper install git go redis ``` After Installing the dependencies mentioned above according to your OS needs, Follow these steps to setup the environment.
Let’s now start with Environment Setup before running Node, Here, you need to setup the following; 1. BSP-Geth & Lighthouse 2. DAS-Pinner Setup 3. BSP-Agent Setup ### 1. BSP-Geth & Lighthouse Setup : Note: The current **BSP-Geth** version is **v2.2.0-bsp**. For the latest updates or additional details, please check the announcements or discussions in **Discord**. Clone the [covalenthq/bsp-geth](https://github.com/covalenthq/bsp-geth/) repo ```shell theme={null} git clone https://github.com/covalenthq/bsp-geth.git cd bsp-geth ``` Build geth (install go if you don’t have it) and other geth developer tools from the root repo with (if you need all the geth related development tools run make all ) ```shell theme={null} make geth ``` Build geth (install go if you don’t have it) and other geth developer tools from the root repo with (if you need all the geth related development tools run make all ) ```shell theme={null} brew services start redis ==Successfully started `redis` (label: homebrew.mxcl.redis) On Linux: systemctl start redis ``` Start `redis-cli` in a separate terminal so you can see the encoded bsps as they are fed into redis streams.
We are now ready to start accepting stream message into redis local ```shell theme={null} redis-cli 127.0.0.1:6379> ``` * Go back to `~/bsp-geth` and start geth with the given configuration, here we specify the replication targets (block specimen targets) with Redis stream topic key replication, in snap syncmode. * Prior to executing, please replace `$PATH_TO_GETH_MAINNET_CHAINDATA` with the location of the mainnet snapshot that you will be downloading in the next step via lighthouse. Everything else remains the same as given below. * Please review the flags and use them according to your system need
Each of the bsp flags and their functions is described below
`--mainnet` - lets geth know which network to synchronize with, this can be `--ropsten`, `--goerli` etc
`--discv5=true`- Enables the node to participate in the Ethereum network's Discovery v5 protocol, which is used for finding peers.
`--txlookuplimit` - Disables the limitation on how far back in the chain transactions are indexed, allowing for retrieval of transaction data from any block in the node’s history.
`--cache` - Sets the memory allocation for the node's cache in megabytes, which is used to improve performance by holding recently accessed data.
`--syncmode` - this flag is used to enable different syncing strategies for geth and a full sync allows us to execute every block from block 0; while snap allows us to execute from live blocks
`--light.ingress` - Limits the bandwidth in kilobytes per second that the node dedicates to serving light clients on Ingress (incoming traffic).
`--light.egress` - Limits the bandwidth in kilobytes per second that the node dedicates to serving light clients on Egress (outgoing traffic).
`--light.maxpeers` - Sets the maximum number of light client peers that the node can connect to.
`--http` - Enable the HTTP-RPC server
`--http.addr` - HTTP-RPC server listening interface (default: localhost)
`--http.api` - API's offered over the HTTP-RPC interface(default: eth,net,web3)
`--http.vhosts` - Allows all virtual hostnames to access the HTTP-RPC server, effectively disabling the host-based security check.
`--ws` - Enable the WS-RPC server
`--ws.addr` - WS-RPC server listening interface (default: localhost)
`--ws.api` - API's offered over the WS-RPC interface (default: eth,net,web3)
`--ws.origins` - Origins from which to accept WebSocket requests
`--datadir` - specifies a local datadir path for geth (note we use “bsp” as the directory name with the Ethereum directory), this way we don’t overwrite or touch other previously synced geth libraries across other chains
`--authrpc.jwtsecret` - Specifies the path to the JWT secret file used for authentication in the RPC API, providing an additional layer of security by requiring tokens for access.
`--replication.targets` - this flag points to redis,  and lets the bsp know where and how to send the bsp messages (this flag will not function without the usage of either one or both of the flags below if both are selected a full block-replica is exported)
`--replica.result` - this flag lets the bsp know if all fields related to the block-result specification need to be exported (if only this flag is selected the exported object is a block-result)
`--replica.specimen` - this flag lets the bsp know if all fields related to the block-specimen specification need to be exported (if only this flag is selected the exported object is a block-specimen)
`—replica.blob` - Enables the extraction of blob specimens as part of the complete block specimen export, which includes state specimens and transaction receipts, collectively referred to as a block replica. This flag is used to include additional block content, particularly useful for nodes participating in more extensive data analysis or archiving, ensuring comprehensive block data is available for these purposes.
`--log.file` - specifies the file location where the log files have to be placed. In case of error (like permission errors), the logs are not recorded in files. Sample Service systemmd file for [BSP-Geth](https://www.covalenthq.com/docs/nodes/block-specimen-producer-onboarding/run-bsp-node#bsp-geth-service-unit-file) can be found here. ```shell theme={null} ./build/bin/geth --mainnet \ --log.debug \ --v5disc=true \ --txlookuplimit=0 \ --cache=8192 \ --syncmode=snap \ --light.ingress=200 \ --light.egress=200 \ --light.maxpeers=3 \ --http=true \ --http.addr=localhost \ --http.api=admin,debug,eth,net,web3,txpool \ --http.vhosts=* \ --ws=true \ --ws.addr=localhost \ --ws.api=admin,debug,eth,net,web3,txpool \ --ws.origins=* \ --datadir=$PATH_TO_GETH_MAINNET_CHAINDATA \ --authrpc.jwtsecret= $PATH_TO_GETH_MAINNET_CHAINDATA/geth/jwtsecret \ --replication.targets=redis://127.0.0.1:6379/0?topic=replication \ --replica.result \ --replica.specimen \ --replica.blob \ --log.file=$PATH_TO_GETH_MAINNET_CHAINDATA/geth/log.log ``` bsp-geth also needs a consensus client. We’ve tested and found the lighthouse to be stable and works well. Goto the [installation instructions](https://lighthouse-book.sigmaprime.io/installation.html) to install it. There are multiple versions of lighhouse available Recommended is to use Pre-built binaries -> releases on github -> Then find a version where the Breaking Changes are none (i.e currently Summer Smith Prime v7.0.1) or you can ask us on the discord for assistance with the version. Then run the lighthouse using: Note: The current **lighthouse** stable version is **v7.0.1**. For the latest updates or additional details, please check the announcements or discussions in **Discord**. Sample Service systemmd file for [lighthouse](https://www.covalenthq.com/docs/nodes/block-specimen-producer-onboarding/run-bsp-node#lighthouse-service-unit-file) can be found here. ```shell theme={null} lighthouse bn \ --network mainnet \ --execution-endpoint http://localhost:8551 \ --execution-jwt $PATH_TO_GETH_MAINNET_CHAINDATA/geth/jwtsecret \ --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \ --disable-deposit-contract-sync ``` Wait for the `eth blockchain` to sync to the tip. Connect to the node’s ipc instance to check how far the node is synced ```shell theme={null} ./build/bin/geth attach $PATH_TO_GETH_MAINNET_CHAINDATA/geth.ipc ``` Once connected, wait for the node to reach the highest known block to start creating live block specimens ```shell theme={null} Welcome to the Geth JavaScript console! instance: Geth/v1.15.11-stable-94f6ae31/linux-amd64/go1.24.0 at block: 22433567 (Wed May 07 2025 18:38:59 GMT+0000 (UTC)) datadir: /scratch/bsp modules: admin:1.0 debug:1.0 engine:1.0 eth:1.0 miner:1.0 net:1.0 rpc:1.0 txpool:1.0 web3:1.0 To exit, press ctrl-d or type exit > eth.syncing { currentBlock: 22433567, healedBytecodeBytes: 0, healedBytecodes: 0, healedTrienodeBytes: 0, healedTrienodes: 0, healingBytecode: 0, healingTrienodes: 0, highestBlock: 22433567, startingBlock: 22432567, syncedAccountBytes: 0, syncedAccounts: 0, syncedBytecodeBytes: 0, syncedBytecodes: 0, syncedStorage: 0, syncedStorageBytes: 0 } ``` Now wait till you see a log from the terminal here with something like this: ```shell theme={null} INFO [04-11|16:35:48.554|core/chain_replication.go:317] Replication progress sessID=1 queued=1 sent=10960 last=0xffc46213ccd3c55b75f73a0bc29c25780eb37f04c9f2b88179e9d0fb889a4151 INFO [04-11|16:36:04.183|core/blockchain_insert.go:75] Imported new chain segment blocks=1 txs=63 mgas=13.147 elapsed=252.747ms mgasps=52.015 number=10,486,732 hash=8b57c8..bd5c79 dirty=255.49MiB INFO [04-11|16:36:04.189|core/block_replica.go:41] Creating Block Specimen Exported block=10,486,732 hash=0x8b57c8606d74972c59c56f7fe672a30ed6546fc8169b6a2504abb633aebd5c79 INFO [04-11|16:36:04.189|core/rawdb/chain_iterator.go:338] Unindexed transactions blocks=1 txs=9 tail=8,136,733 elapsed="369.12µs" ``` This can take a few days or a few hours depending on if the source chaindata is already available at the datadir location or live sync is being attempted from scratch for a new copy of blockchain data obtained from syncing with peers. In the case of the latter the strength of the network and other factors that affect the Ethereum network devp2p protocol performance can further cause delays. Once blockchain data state sync is complete and eth.syncing returns false. You can expect to see block-specimens in the redis stream. The following logs are captured from bsp-geth service as the node begins to export live Block Specimens.
The last two logs show that new block replicas containing the block specimens are being produced and streamed to the redis topic `replication`. After this you can check that redis is stacking up the bsp messages through the redis-cli with the command below (this should give you the number of messages from the stream) ```shell theme={null} $ redis-cli 127.0.0.1:6379> xlen replication 11696 ``` If it doesn’t - the BSP producer isn't producing messages! In this case please look at the logs above and see if you have any WARN / DEBUG logs that can be responsible for the disoperation. For quick development iteration and faster network sync - enable a new node key to quickly re-sync with the ethereum network for development and testing by going to the root of `go-ethereum` and running the bootnode helper. NOTE: To use the bootnode binary execute make all in place of make geth, this creates all the additional helper binaries that bsp-geth ships with. ```shell theme={null} ./build/bin/bootnode -genkey ~/.ethereum/bsp/geth/nodekey ``` ### 2. DAS-Pinner Setup DAS-Pinner serves as the interface to the storage layer of the network. It's a lightweight IPFS service that stores and pins data on the IPFS network using web3.storage. It is designed to work seamlessly with the DAS Light-Client, enabling the retrieval of data from the IPFS network and its verification using the DAS protocol.
It is meant for uploading/fetching network artifacts (like block specimens and block results or any other processed block data) files of the Covalent Decentralized Network. Current : `Go Version: go1.22 or later` , this could change later in time please cross check with operator-releases channel on discord for correct versions. Note: The current **DAS-Pinner** stable version is **v0.17.6**. For the latest updates or additional details, please check the announcements or discussions in **Discord**. Clone and build [das-pinner](https://github.com/covalenthq/ewm-das/) (in a separate folder) We store the block specimens in the ipfs network. Bsp-agent interacts with the das-pinner server to handle the storage/retrieval needs of the network. ```shell theme={null} $ cd .. $ git clone https://github.com/covalenthq/ewm-das.git $ cd ewm-das $ git checkout tags/v0.17.6 ## update if newer release is announced $ ./install-trusted-setup.sh $ make build-pinner ``` Setting up w3cli `Software Prerequisite - Node.Js version 18 or higher and npm version 7` * **Install w3cli Version 7.9.1:** To install version 7.9.1 of the w3cli tool globally on your system, run the following command: ```shell theme={null} npm install -g @web3-storage/w3cli@v7.9.1 ``` * Troubleshooting: If you encounter any issues, such as missing dependencies, try clearing the npm cache and reinstalling w3cli: ```shell theme={null} npm cache clean --force npm uninstall -g @web3-storage/w3cli npm install -g @web3-storage/w3cli@v7.9.1 ``` Additionally, you can manually install any missing dependencies. ```shell theme={null} npm install -g crypto-random-string ``` Get the agent key, did and delegation proof from Covalent, then you can run the ipfs-pinner ipfs-pinner can be run as a server and allows two functionalities currently -  `/get` and `/upload` With this, the ipfs-pinner is setup and can `upload/fetch` network artifacts. Sample Service systemmd file for [ipfs-pinner](https://www.covalenthq.com/docs/nodes/block-specimen-producer-onboarding/run-bsp-node#ipfs-pinner-service-unit-file) can be found here. ```shell theme={null} $ cat .envrc export AGENT_KEY="<>" export W3_DELEGATION_FILE="<< ASK_ON_DISCORD>>" $ ./build/bin/server -w3-agent-key -w3-delegation-file ``` ### 3. BSP-Agent Setup: #### Install Dependencies * Install direnv #### MacOS 12.x (M1/Intel) ```shell theme={null} brew install direnv ``` #### Debian/Ubuntu ```shell theme={null} apt install direnv ``` #### Fedora ```shell theme={null} dnf install direnv ``` #### RHEL/CentOS ```shell theme={null} yum install direnv ``` #### SLES/OpenSUSE ```shell theme={null} zypper install direnv ``` `direnv` manages and controls sensitive information for the agent, such as Ethereum private keys for operator accounts on the Covalent Network and Redis access passwords. This is crucial since these applications, exposed on HTTP ports, must not log sensitive data.
To enable direnv on your machine add these to your `~./bash_profile` or `~./zshrc` depending on which you use as your default shell after installing it using brew.
For bash users - add the following line to your `~/.bashrc`
For zsh users - add the following line to your `~/.zshrc` ```bash bash theme={null} eval "$(direnv hook bash)" ``` ```bash zsh theme={null} eval "$(direnv hook zsh)" ``` After adding this line do not forget to source your bash / powershell config with the following, by running it in your terminal. ```bash bash theme={null} source ~/.bashrc ``` ```bash zsh theme={null} source ~/.zshrc ``` # EWM Light Client Onboarding Source: https://covalenthq.com/docs/nodes/ewm-light-client/ewm-lc-home The **EWM Light Client** is a new and pivotal component of the Covalent Network, designed to ensure the secure, decentralized verification of blockchain data, specifically within the Ethereum ecosystem. As part of the broader Ethereum Wayback Machine (EWM) initiative, the EWM Light Client enables users to participate in the network without needing to run full nodes, making the network more accessible and enhancing its decentralization. This client plays a crucial role in scaling the verification of proofs in the network and contributing to the long-term availability of Ethereum’s transactional history Note:The EWM Light Client is open-source; however, only verified participants from the official waitlist will be eligible for mainnet access and future rewards. Join the EWM Light Client waitlist by filling out this [form](https://forms.gle/sS1RDAgUwju7UQV19). ### Hardware Requirements #### Minimum Requirements * **CPU:** 1+ cores * **RAM:** 1.5 GB * **Storage:** 1.5 GB * **Internet:** Stable connection #### Recommended * **CPU:** Multi-core for enhanced performance * **RAM:** 4 GB * **Storage:** 10 GB * **Internet:** Stable connection ### Software Requirements Ensure the following software is installed with the specified versions: * **Operating Systems:** macOS or Linux * **Docker** * **Go:** Version 1.22 or later * **Git** * **IPFS** * **EWM Light Client** *** **Additional Recommendations:** * **Docker:** Make sure Docker is properly configured and running, as it simplifies the deployment process. * **IPFS:** Familiarize yourself with IPFS basics to effectively utilize the EWM Light Client. * **Updates:** Regularly update your software to the latest versions to benefit from security patches and new features. *** # Setup EWM Light Client Node Source: https://covalenthq.com/docs/nodes/ewm-light-client/lc-setup ### Prerequisites for Running the EWM Light Client To participate in running an EWM Light Client, you must join the exclusive waitlist. Provide your name and email by filling out this [form](https://forms.gle/sS1RDAgUwju7UQV19). Note: The EWM Light Client is open-source; however, only verified participants from the official waitlist will be eligible for testnet/mainnet access and future rewards. Once you receive whitelist instructions via email, you will be required to submit two addresses: 1. **Light Client Owner Address (Mainnet Wallet Address):** * This address will receive rewards during the testnet phase and will be used to get whitelisted for the mainnet launch. 2. **Burner Address:** * This address should **not** hold any funds. It will be used by the light client to sign the work that's been done. You can generate a burner address using the following resources: **Important:** Save both the private key and public address. **Only** share the public address with us. * [Visual-Key](https://visualkey.link/) * [Vanity-ETH](https://vanity-eth.tk/) * [Eth-Vanity](https://eth-vanity.io/#calc) ### Install Dependencies / Prerequisites You can set up the EWM Light Client in four ways. Follow the appropriate dependencies based on your chosen method: * **Run with Docker Compose** * **Run with Installer for MacOS** * **Run with pre-complied binaries** * **Run from Source** *** ### Dependencies to Run with Docker Compose: **Install Docker:** 1. Follow the [Docker installation instructions](https://docs.docker.com/engine/install/) for your specific platform and architecture. *** ### Dependencies to Run via Installer/ Pre-complied binaries/ Source: For more details on releases and installation instructions, visit the [Go Downloads page](https://go.dev/dl/). **MacOS:** ```shell theme={null} brew install go ``` **Linux:** ```shell theme={null} wget https://go.dev/dl/go1.22.3.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.22.3.linux-amd64.tar.gz echo "" >> ~/.bashrc echo 'export GOPATH=$HOME/go' >> ~/.bashrc echo 'export GOROOT=/usr/local/go' >> ~/.bashrc echo 'export GOBIN=$GOPATH/bin' >> ~/.bashrc echo 'export PATH=$PATH:/usr/local/go/bin:$GOBIN' >> ~/.bashrc source ~/.bashrc ``` **Verify Go Installation:** ```shell theme={null} go version ``` *Expected output: `go version go1.22.x ...`* Follow the instructions to install IPFS from the [official IPFS installation guide](https://docs.ipfs.tech/install/command-line/#system-requirements). **MacOS:** ```shell theme={null} brew install ipfs ``` **Linux:** ```shell theme={null} wget https://dist.ipfs.tech/kubo/v0.30.0/kubo_v0.30.0_linux-amd64.tar.gz tar -xvzf kubo_v0.30.0_linux-amd64.tar.gz ``` **Install IPFS:** ```shell theme={null} cd kubo sudo bash install.sh ``` *This will move the `ipfs` binary to `/usr/local/bin`.* **Verify IPFS Installation:** ```shell theme={null} ipfs --version ``` *Expected output: `ipfs version 0.30.0`* # Run EWM Light Client Source: https://covalenthq.com/docs/nodes/ewm-light-client/run-ewm-lc The **EWM Light Client** can be run using four methods. Follow the instructions below based on your preferred approach: * **Run with Docker Compose** * **Run with Installer for macOS** * **Run with Pre-complied Binaries** * **Build & Run from Source** *** ## 1. Run with Docker Compose ### Instructions to Run EWM Light Client with Docker ```shell theme={null} git clone https://github.com/covalenthq/ewm-das cd ewm-das ``` ```shell theme={null} docker build -t covalent/light-client -f Dockerfile.lc . ``` **Note:** If you are running the client on **Windows**, you may have to modify the Dockerfile.lc script since the lining on Windows is different than Linux. #### For Windows: ```shell theme={null} # Install dos2unix to fix line endings RUN apk add --no-cache dos2unix ``` You need to provide the `PRIVATE_KEY` of your burner address, which was generated as part of [Prerequisites Step 2](/docs/ewm-light-client/lc-setup/). ```shell theme={null} docker run -d --restart always --name light-client -e PRIVATE_KEY="YOUR_HEX_PRIVATE_KEY" covalent/light-client ``` ```shell theme={null} docker logs -f light-client ``` **Expected Output:** For version details, please refer to our Discord's `light-client` channel. ```bash theme={null} Version: v0.x.0, commit: 8d6709bee9e79d3c4e6ece35fed65da02f3850f4 2024-09-18T15:45:01.238-0700 INFO light-client light-client/main.go:91 Starting client... 2024-09-18T15:45:01.238-0700 INFO light-client light-client/main.go:97 Client identity: 0x51b6D674514849aF97FB77BCac51bcdD7799842C ... ``` ## 2. Run using Installer for macOS only: ### Running Light Client on macOS ```shell theme={null} brew install ipfs ``` ```shell theme={null} ipfs init ``` You need to provide the `PRIVATE_KEY` of your burner address, which was generated as part of [Prerequisites Step 2](/docs/ewm-light-client/lc-setup/). **Single Command Installation:** ```shell theme={null} curl -sSf https://storage.googleapis.com/ewm-release-artefacts/{{VERSION}}/macos/install.sh | bash -s ``` **Alternative Installation Method:** 1. Go to the [Light Client Releases](https://github.com/covalenthq/ewm-das/releases) page and download the latest release. 2. Unzip the downloaded archive and navigate to the directory: ```shell theme={null} cd das-macos-latest ``` 3. Run the installation script: ```shell theme={null} ./install.sh ``` *The script will install all files in the `$HOME/.covalent` directory.* ```shell theme={null} tail -n 1000 -f $HOME/.covalent/light-client.log ``` **Expected Output:** For version details, please refer to our Discord's `light-client` channel. ```shell theme={null} Version: v0.x.0, commit: 8d6709bee9e79d3c4e6ece35fed65da02f3850f4 2024-09-18T15:45:01.238-0700 INFO light-client light-client/main.go:91 Starting client... 2024-09-18T15:45:01.238-0700 INFO light-client light-client/main.go:97 Client identity: 0x51b6D674514849aF97FB77BCac51bcdD7799842C ... ``` ```shell theme={null} $HOME/.covalent/uninstall.sh ``` *** ## 3. Run with Pre-complied Binaries ### Running from Binaries ```shell theme={null} brew install ipfs ``` ```shell theme={null} ipfs init ``` Get the required pre-compiled binaries for Ubuntu or macOS from the [Releases](https://github.com/covalenthq/ewm-das/tags) page. You need to provide the `PRIVATE_KEY` of your burner address, which was generated as part of [Prerequisites Step 2](/docs/ewm-light-client/lc-setup/). ```shell theme={null} ./bin/light-client --rpc-url \ --collect-url \ --private-key ``` **Command:** ```shell theme={null} ./bin/light-client --rpc-url ws://coordinator.das.test.covalentnetwork.org/rpc --collect-url https://us-central1-covalent-network-team-sandbox.cloudfunctions.net/ewm-das-collector --private-key ${PRIVATE_KEY} ``` ```shell theme={null} tail -n 1000 -f $HOME/.covalent/light-client.log ``` *** ## 4. Build & Run from Source ### Building from the Source ```shell theme={null} git clone https://github.com/covalenthq/ewm-das cd ewm-das ``` ```shell theme={null} make deps ``` ```shell theme={null} make ``` **Note:** The binaries will be built in the `bin` directory. You need to provide the `PRIVATE_KEY` of your burner address, which was generated as part of [Prerequisites Step 2](/docs/ewm-light-client/lc-setup/). ```shell theme={null} ./bin/light-client --rpc-url \ --collect-url \ --private-key ``` **Command:** ```shell theme={null} ./bin/light-client --rpc-url ws://coordinator.das.test.covalentnetwork.org/rpc --collect-url https://us-central1-covalent-network-team-sandbox.cloudfunctions.net/ewm-das-collector --private-key ${PRIVATE_KEY} ``` ```shell theme={null} tail -n 1000 -f $HOME/.covalent/light-client.log ``` **Expected Output:** For version details, please refer to our Discord's `light-client` channel. ```shell theme={null} Version: v0.x.0, commit: 8d6709bee9e79d3c4e6ece35fed65da02f3850f4 2024-09-18T15:45:01.238-0700 INFO light-client light-client/main.go:91 Starting client... 2024-09-18T15:45:01.238-0700 INFO light-client light-client/main.go:97 Client identity: 0x51b6D674514849aF97FB77BCac51bcdD7799842C ... ``` To remove build artifacts, run: ```shell theme={null} make clean ``` # Overview Source: https://covalenthq.com/docs/nodes/overview Critical to the Covalent Network are the Network Operators. These act as points of presence on the network that fulfill various duties necessary to enable a decentralized blockchain data indexing and querying model. Each operator is compensated in CXT for the work performed. **Interested in helping the Covalent Network grow?**
Apply to become a Covalent Network Operator today [Learn More](https://app.deform.cc/form/c4dfdd2c-3308-4eb9-9e70-5567126d97d1) Any Network Operator may function in one or all of the live network roles. The roles have very different operational requirements, however, so it is expected that Network Operators will self-select into the subset of roles that best suit their capabilities. The roles are: * Block Specimen Producer (BSP) * Block Results Producer (BRP) * EWM Light Client * Query Node Operator (QNO) * Delegator Currently, whitelisted operators are operating as Block Specimen Producers and Block Results Producers. As the network is developed, this whitelist will expand and over time, extinguished. As further roles are developed and the Covalent Network scales, operators will be able to expand into other roles. [Staking](https://www.covalenthq.com/staking/#/) is also live. CXT holders who don't wish to run a node on the Covalent Network can delegate their tokens to Network Operators. ### Operator expectations * Reliable connection to the Covalent Network (low latency, high uptime) * Robust security practices and network architecture * Meet the staking parameters * Running latest Covalent Network Node software releases * Participation in governance (when applicable) ### Staking parameters The current system parameters are [here](/docs/resources/system-parameters). * The minimum staking amount for a Block Specimen Producer is 175,000 CXT and 35,000 CXT for a Block Results Producer. * There is an unbonding period of 180 days for operators. During this period, rewards cease to be added to the principal amount staked. * The fees which delegates pay to operators can be changed by the owner and has a minimum of 2%. It can be different for each operator as they ultimately control the fee. * There is a maximum ratio of delegated CXT to operator self-stake CXT. * There is a max stake in place for operators to prevent a small number of Network Operators making up the majority staked. ### Running as an Operator Find the hardware and software requirements for each respective operator role below as well as source code and further details. An overview of various roles on the Covalent Network How to run a BSP Node How to run a BRP Node # Block Results Producer Source: https://covalenthq.com/docs/nodes/quick-start/block-results-producer-brp The Block Results Producer is a concurrent Block Specimen data processing framework designed for scalable and verified data transformations. The output, one of many possible, is a Block Result; a one-to-one representation of block data returned from an RPC call to a blockchain node with optional and additional informative fields. And importantly, the BRP can perform arbitrary transformations over any input Block Specimens concurrently with other transformations, which essentially means that the BRP can concurrently re-execute Ethereum blocks and transactions completely external to their source blockchain node client software, something that no blockchain node clients can currently do. By leveraging the BRP's concurrent processing capability, one can effortlessly perform customizable data indexing with minimal overhead. The Block Results consequently indexed will power products such as [GoldRush's API](https://www.covalenthq.com/docs/unified-api/) and is the first of many steps needed to build our vision of a truly decentralized data infrastructure aimed at solving Ethereum's long-term data availability and read scalability problem. ### Enrichment With the BRP live, Block Specimens can be enriched and transformed into Block Results by multiple operators on the Covalent Network. These verified Block Results can then be retrieved and indexed by anyone utilizing the Covalent Network for decentralized data access without the overhead of running full blockchain client nodes. The net result is that anyone will be able to pull historical and live blocks that are complete with the data one could retrieve by calling the JSON-RPC layer but without the bottlenecks associated with the latter method. Furthermore, anyone wishing to analyze this data or build a web3 data application on top of the Covalent Network, such as block explorers, can pull this type of granular data without running a node. An Ethereum transaction tracing engine is also on its way to unlock deeper insights into an Ethereum transaction. This work is iterative and research-oriented in nature (unlike Block Specimen to Block Result transformation, which is stable). The concurrent nature of BRP's Block Specimen execution means that the network can quickly run all Ethereum blocks through the tracing engine. ### Hardware Requirements The recommended configurations will make sure the sync is not lag prone and the node is able to keep up with the Ethereum network. #### Minimum * 2 vCPUs (cores) * 3GB RAM * 200GB HDD free storage (mostly storing artifacts on local ipfs; can be pruned periodically) * 8 MBit/sec download Internet service #### Recommended * 4 vCPUs * 8 GB+ RAM * SSD with >= 500GB storage space * 25+ MBit/sec download Internet service #### Software Requirements (Docker Setup) * 64-bit Linux, Mac OS 13+ * SSL certificates * docker, docker-compose, direnv #### Resources # Block Specimen Producer Source: https://covalenthq.com/docs/nodes/quick-start/block-specimen-producer-bsp Essential to the Covalent Network is the *Block Specimen* and the *Block Specimen Producer* (BSP), a bulk export method that ultimately leads to generating a canonical representation of a blockchain's historical state. Currently implemented on existing blockchain clients running Geth. It currently functions as a: * Blockchain data extractor * Blockchain data normalizer What is ultimately created is a Block Specimen, a universal canonical representation of a blockchain’s historical state. There are two further considerations regarding the Block Specimen. * The BSP is completely standalone on the forks of Geth. * The separation of data storage layer from the block execution and distributed consensus functionality leads to better segregation and upgrades of functionality in the blockchain data processing pipeline. As a result, anyone can run full tracing on the block specimen and accurately recreate the blockchain without access to blockchain client software. ### Hardware Requirements The recommended configurations will make sure the sync is not lag-prone and the node is able to keep up with the Ethereum network. #### Minimum Requirements: * CPU with 4+ cores * 16GB RAM * 1.5TB free storage space to sync the Ethereum Mainnet * 8 MBit/sec download Internet service #### Recommended: * Fast CPU with 8+ cores * 32 GB+ RAM * Fast SSD with >= 1.5TB storage space * 25+ MBit/sec download Internet service ### Software Requirements Install the given versions of the following software: * 64-bit Linux, Mac OS * SSL certificates * Git * BSP-geth v1.8.0-bsp ships with - Geth v1.13.14-stable * Go v1.20 * Redis v7, Redis-cli 7.\* * Listener TCP and UDP discovery port 30303 * ICMP IPv4 should not be closed by an external firewall #### Resources # Deciding which Node to run Source: https://covalenthq.com/docs/nodes/quick-start/quick-start Now that you have understood the basic operations on the Covalent Network, you can start exploring which nodes to run. The Block Specimen Producer securely extracts data from blockchains, creating what is known as *Block Specimens* - a bulk export method that ultimately leads to the generation of a canonical representation of a blockchain's historical state. The Block Results Producer re-executes or processes the Block Specimens further, producing enriched data outputs called *Block Results*, a comprehensive representation of block data returned from an RPC call to a blockchain node, with additional fields for in-depth analysis. # Security and Audits Source: https://covalenthq.com/docs/resources/audits Covalent places significant emphasis on security. The Covalent Network has been designed to be safe and secure, and we've has spent all the necessary resources in order to ensure that the network matches the highest security standards. Below are the links to all audit reports for the Covalent Network: ## Staking Contract Audits
Quantstamp Audit Round 4 - Covalent Network Staking Contract Sherlock Audit Round 4 - Covalent Network Staking Contract Quantstamp Audit Round 3 - Covalent Network Staking Contract SafePress Audit Round 3 - Covalent Network Staking Contract Quantstamp Audit Round 2 - Covalent Network Staking Contract SafePress Audit Round 2 - Covalent Network Staking Contract FairyProof Audit Round 2 - Covalent Network Staking Contract Hacken Audit Round 1 - Covalent Network Staking Contract Quantstamp Audit Round 1 - Covalent Network Staking Contract ## CQT Token Contract Audits QuantStamp Audit - CQT Smart Contract Certik Audit - CQT Smart Contract ## CXT Token Contract Audits QuantStamp Audit - CXT Smart Contract Hacken Audit - CXT Smart Contract QuillAudit Audit - CXT Smart Contract # Block Result Producer Whitepaper Source: https://covalenthq.com/docs/resources/block-result-producer-whitepaper Click here to read BRP Whitepaper # Block Specimen Whitepaper Source: https://covalenthq.com/docs/resources/block-specimen-whitepaper Click here to read BSP Whitepaper # Contract Addresses Source: https://covalenthq.com/docs/resources/contract-addresses ## Setup your development CXT on Base is a bridged asset, i.e. the corresponding CXT is locked on the Ethereum side and does not increase the total supply of CXT. | Contract | Network | Address | | ----------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------- | | CXT Contract Address | Ethereum | [0x7ABc8A5768E6bE61A6c693a6e4EAcb5B60602C4D](https://etherscan.io/token/0x7ABc8A5768E6bE61A6c693a6e4EAcb5B60602C4D) | | Base CXT Contract Address (Bridged) | Base | [0xB1E1f3Cc2B6fE4420C1Ac82022b457018Eb628ff](https://basescan.org/token/0xb1e1f3cc2b6fe4420c1ac82022b457018eb628ff) | | CXT Uniswap Pool | Ethereum | [0xc783d210c483d76d158fd502af6b48439ffed9c5](https://etherscan.io/address/0xc783d210c483d76d158fd502af6b48439ffed9c5) | | CXT Staking Contract Address | Ethereum | [0xfe97b0C517a84F98fc6eDe3CD26B43012d31992a](https://etherscan.io/address/0xfe97b0C517a84F98fc6eDe3CD26B43012d31992a) | | ProofChain Contract | Moonbeam | [0x7487b04899c2572A223A8c6eC9bA919e27BBCd36](https://moonscan.io/address/0x7487b04899c2572A223A8c6eC9bA919e27BBCd36) | ### Deprecated | Contract | Network | Address | | --------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------- | | CQT Contract Address (deprecated) | Ethereum | [0xD417144312DbF50465b1C641d016962017Ef6240](https://etherscan.io/token/0xd417144312dbf50465b1c641d016962017ef6240) | # Covalent Network Whitepaper Source: https://covalenthq.com/docs/resources/covalent-network-whitepaper Click here to read Network Whitepaper # Delegator FAQ Source: https://covalenthq.com/docs/resources/delegator-faq Staking your CXT can be completed via the [Covalent Network Staking Dashboard](https://www.covalenthq.com/staking/#/).
For a complete guide, please visit the 'Staking Guide'. Delegators can choose to stake their tokens to any registered Covalent Network Operator. The main factors for delegators in choosing a Network Operator include the performance, the commission rate set by the Network Operator, and the reputation/experience of the Network Operator.
After researching the Network Operators and understanding the risks involved, delegators can decide the number of tokens they want to delegate and which Network Operator they will delegate to. Yes. You would first have to unstake your stake however and Restake it to your choice of operator. For every piece of ‘work’ Network Operators perform such as producing a Block Specimen, a respective proof is published to the [ProofChain Contract](resources/glossary). Publishing proofs is a key mechanism in ensuring that the data Operators produce is honest and trustworthy. Publishing proofs on Ethereum Mainnet would have ridiculous costs. Hence, Moonbeam was selected as the settlement layer of the Covalent Network. Rewards can be claimed immediately. There is no minimum delegation amount. There is, however, a maximum cap that Operators can accept in delegations due to the MaxCap Multiplier staking parameter. Hence, some may be unavailable for delegating. This cap will be increasing with time however and as a result, more space will become available to stake with Network Operators. Given that slashing is not live on the Covalent Network yet, there is no risk of your delegated CXT being slashed. The primary risk is that the staking contract is compromised. However, to mitigate this risk, the contract has undergone multiple audits. These can be found here: [Security & Audits](resources/audits) There is a cool-down period of approx 14 days. This only applies to the amount delegated and not your rewards available. Rewards can be redeemed immediately. If a CXT token holder decides to stake CXT tokens with an Operator, the delegator will receive a portion of the rewards that the respective Operator has earned proportionate to the total amount staked. The delegator also has to consider the commission fee set by the Operator. This fee is charged as Operators have to pay the expense of running the infrastructure necessary for operating on the Covalent Network. While CXT is held in the staking contract, it is only the owner of the respective staked CXT that can interact with it. # Staking Emission Schedule Source: https://covalenthq.com/docs/resources/emission-schedule At genesis of the Covalent Network, 8% of the CXT supply (80m CXT) was allocated to bootstrap the network over 4 years. As more roles come online with the decentralization network, the emission rate will be increased through a governance process to support the network. | Year | Budget | Emissions | | ---- | ------: | --------: | | 2022 | 20m CXT | \~10m CXT | | 2023 | 20m CXT | \~10m CXT | | 2024 | 20m CXT | \~24m CXT | | 2025 | 20m CXT | N/A | # Ethereum Wayback Machine Whitepaper Source: https://covalenthq.com/docs/resources/ethereum-wayback-machine Click here to read EWM Whitepaper # EWM Light Client Whitepaper Source: https://covalenthq.com/docs/resources/ewm-light-client-whitepaper Click here to read EWM Light Client Whitepaper Click here to read EWM Light Client Whitepaper in Chinese Click here to read EWM Light Client Whitepaper in Vietnamese Click here to read EWM Light Client Whitepaper in Korean Click here to read EWM Light Client Whitepaper in Turkish # Glossary Source: https://covalenthq.com/docs/resources/glossary ## Covalent Network The Covalent Network represents the progressive decentralization of Covalent towards a community-owned and community-run protocol.
A multi-sided platform designed to eventually be self-sufficient, the Covalent Network works by capturing and indexing blockchain data and storing it across multiple points on the network. Anyone can then access this data instantly through querying the GoldRush API. A collection of network participants who perform various roles in the network in extracting, transforming, tracing, indexing, delegating, governing, providing queries all the while making proofs-of-work done for receiving per block-rewards on a public blockchain. A blockchain client that asynchronously exports rich, cryptographically-secure data as block specimens. The BRP engine traces, decodes and enriches the block specimens into block results and aggregatable traces. The subset of operators that host the decentralized database with the indexed blockchain data and a layer to extract insights from contract state snapshots allowing API calls to retrieve it. The subset of operators that delegate their CXT to stake within a pool of producers, auditors, refiners, indexers, queriers and receive a portion of the rewards of the work done by them proportional to their stake in the roles. They also participate in governance based on their stake in the evolution of functions undertaken by various roles in the network. The subset of operators from the pool that check the work of producers and prove when asked to - the work done by them on a public EVM chain. The Block Specimen is a bulk export method that can be implemented on existing blockchain clients including Geth and Erigon. These patches are essentially an extract-and-normalize worker that create Block Specimens, which together form a canonical representation of a blockchains full historical state. A transformed Block Specimen that is organized in a schema the Covalent database expects. The ProofChain contract is a smart contract that 1. Records information that meet specific validation rules and 2. Determines consensus on network rewards by comparing these inputs. With regard to the information recorded, these are proofs in the form of hashes. A proof is generated for every Block Specimen created by a Block Specimen Producer and submitted to the ProofChain contract, along with some other identifying information. # Governance Source: https://covalenthq.com/docs/resources/governance How to participate in governance The CXT token will be gradually used to remove the need for the Covalent team to be a key player for the management, storage, and relaying of data on the network, by allowing holders to vote on network features. Instead, we will have an ecosystem of multiple data-providers and a variety of data queried through the network without a single party deciding on it (for the avoidance of doubt, the right to vote is restricted solely to voting on features of the Covalent Network; the right to vote does not entitle CXT holders to vote on the operation and management of any entity developing the Network, its affiliates, or their assets, and does not constitute an equity interest in any of these entities). This is part of the reason why we give tokens to vendors on the network that provide data during the initial phases of the project. By incentivizing those that are net beneficial to the network, we are curating a community of the world’s best data-vendors to manage the Covalent Network. ## Pitching a Covalent Network Improvement Proposal When submitting a proposal, please refer to the template outlined below. Proposals could include but are not limited to: * Indexing a blockchain * Adding a specific protocol endpoint * Research ideas for Alpha Alarm * Suggestions to the Alchemist Program * Participating in different farming/staking programs * Developer adoption and marketing initiatives, such as running hackathons and localization of content Proposals that will not get accepted: * Listing on exchanges * Token burning * Anything that could cause others harm and/or that is illegal ## Governance Forum Template The proposal you are submitting should include the following: * A concise title * Author(s) (Twitter IDs) * Background (Tell us about yourself and your interests in writing the proposal) * Date * Summary (A synopsis of the item for the Covalent Network to consider) * Mission and Value Alignment (The expected benefit to the Network) * Financial Implication (The expected cost to the Network or resources that may be required) * Poll (Using the Discourse poll feature) ## Proposal Consensus Levels The consensus levels for a specific proposal move from one stage to the next. First, the proposer writes the proposal on our Governance Forum, followed by a proposal voting in the Covalent [Discord server](https://www.covalenthq.com/discord/). Based on the responses and soft votes on the forum as well as Discord, the Covalent team will decide to take the proposal to Snapshot for final approval/voting. To summarize: * Governance Forum (Discourse Votes): Consensus Level = Gauging Support * Discord Votes: Consensus Level = Confirmed Support * Snapshot Votes: Consensus Level = Final approval ## Creating a Proposal The threshold to create a proposal at the moment is 5000 CXT. However, to bootstrap the initial governance process only whitelisted members (Covalent team) will be able to create proposals on Snapshot. ## Voting Power In order to vote on the given proposal, you need to have a sufficient amount of CXT to add in your vote. The voting power for Governance V1 is 1 CXT = 1 Vote. Your CXT will stay in your wallet. You will only have to sign the vote (transaction) on Snapshot. It also means you do not have to spend on the gas fees. ## Quorum The minimum quorum for the proposal to pass will be defined by following: * Greater than (>) 55% vote approval * A minimum of 10000 votes All the governance proposals that go on Snapshot will get 2 to 6 days to vote. If the above quorum is reached after the stipulated time, Covalent will execute the vote in accordance with the majority. NOTE: The CXT tokens need to be in the wallet before the proposal goes live on Snapshot as defined by the block # for the proposal. If you buy CXT or transfer CXT to the wallet after the proposal goes live, you won’t be able to vote on that proposal. # EWM Light Client FAQ Source: https://covalenthq.com/docs/resources/light-client-faq The leaderboard resets daily, so you will only see your address listed if your Light Client was active that day. Yes! The higher your uptime, the more tasks you will receive. For example, if your LC has 12 hours of uptime, you will receive significantly more tasks compared to only 1, 2, or 3 hours of uptime. Yes, you are responsible for backing up the wallet you create to run the LC. However, keep in mind that you will use a different wallet for the mainnet. Valid testnet participants will receive bonus rewards on top of the rewards they earn when running the Light Client on mainnet. Yes! You can run multiple Light Clients using the same burner address, but you will need to create different IDs for each one. You can join our Discord channel to speak with the team or connect with others running Light Clients. You will need 5000 CXT per Light Client on mainnet. Yes! The Light Client is lightweight and open-source, so you can easily run it alongside other infrastructure. Mainnet onboarding will occur in seasons, with each season onboarding roughly 2000 Light Clients. Yes, your initial stake of 5000 CXT will be returned when you are done running the Light Client. # Operator FAQ Source: https://covalenthq.com/docs/resources/operator-faq A proper incentive structure must be in place for any decentralized structure to succeed. This is especially important in the enforcement of good behavior on the network. Thus, there is a minimum staking requirement of 175,000 CXT for Block Specimen Producers and 35,000 CXT For Block Result Producer - Refiners. Staking assets are used as collateral to register operators in the consensus process. This means that while assets are staked, they are held in an escrow on the network. Consequently, staked assets are inaccessible to the token holder while they are being used to secure the network. Please fill out this [form](https://app.deform.cc/form/c4dfdd2c-3308-4eb9-9e70-5567126d97d1) Also, you can reach out to the core team in Covalent's community Discord for more information. Anybody can generate and submit improvement proposals. While Discourse is the primary tool at this moment to discuss the governance of Covalent, on-chain votes will happen on Snapshot. If a proposal has passed, it will be reviewed by the core Covalent Engineering team and implemented. Overtime, it is expected that as the Covalent becomes more open source, changes will be implemented by community stewards. More information can be found [here](resources/governance) In the Operator address. There is an undelegation period of 6 months for operators of the Covalent Network. Rewards can be redeemed immediately, however. No ### BSP Requirements #### Minimum Requirements: * CPU with 4+ cores * 16GB RAM * 1.5TB free storage space to sync the Mainnet * 8 MBit/sec download Internet service #### Recommended: * Fast CPU with 8+ cores * 32 GB+ RAM * Fast SSD with >= 1.5TB storage space * 25+ MBit/sec download Internet service #### Software Requirements: * Install the given versions of the following software: * 64-bit Linux, Mac OS * Git * BSP-geth v1.8.0-bsp ships with - Geth v1.13.14-stable * Go v1.20 * Redis v7, Redis-cli 6.2.5 * Listener TCP and UDP discovery port 30303 * ICMP IPv4 should not be closed by an external firewall ### Refiner Requirements #### Minimum requirements: * 2 vCPUs (cores) * 3GB RAM * 200GB HDD free storage (mostly storing artifacts on local ipfs; can be pruned periodically) * 8 MBit/sec download Internet service #### Recommended: * 4 vCPUs * 8 GB+ RAM * SSD with >= 500GB storage space * 25+ MBit/sec download Internet service #### Software Requirements (docker setup): * 64-bit Linux, Mac OS 13+ * SSL certificates * docker, docker-compose, direnv Max Cap Multiplier is the ratio of Operator-staked tokens to delegator-staked tokens. For example, with a ratio of 1:10, if a Network Operator stakes 1 CXT, they are only eligible to accept 10 delegated CXT. This is a mechanism to prevent a centralized group of Operators where the majority of delegated CXT is staked with a select few. Slashing will exist on the Covalent Network eventually. Initially, however, there is no slashing. For those who are deemed to be acting dishonestly following the auditing process, rewards will not be distributed. Slashing updates will be provided well in advance of the functionality being implemented. Proofs are created to ensure that the work the operator has produced is honest and valid. The contract in which operators are submitting these proofs is deployed on MoonBeam given the low settlement costs for doing so. If this contract was deployed on Ethereum, the gas costs would be substantial. Yes. To make this change, use the change address button, confirm the transaction and connect with the new wallet. If an Operator makes this change, the new address cannot be the same as one of the delegate addresses # System Parameters Source: https://covalenthq.com/docs/resources/system-parameters Learn how to preview changes locally There are a number of system parameters in place that are dynamic and can be updated. These are in place to: 1. Prevent a small number of Network Operators making up the majority staked, and 2. To manage the system as its scale increases. These parameters will be periodically examined and adjusted. The parameters at launch are as follows: | Block Specimen Producer | Rate | | :------------------------ | ----------: | | Max Stake | 350,000 CXT | | MaxCap Multiplier | 34:1 | | Minimum Stake Requirement | 175,000 CXT | | Block Results Producer | Rate | | :------------------------ | ---------: | | BRP Max Stake | 70,000 CXT | | MaxCap Multiplier | N/A | | Minimum Stake Requirement | 35,000 CXT |